Learn Software Development » UI

The compromise between having a Product Owner who tries to detail out too much ..

ashish — Mon, 17 Oct 2011 17:42:00 +0000

Scrum suffers from problems where you have a Product Owner role that needs to have a person who has understood the role in good detail. In a lot of cases, just transitioning the role from that of a regular Product Management role to that of a Product Owner role takes some amount of getting used to. So, you need to have a Product Owner who is setup to define a level of responsibility where the Product Owner gives enough detail about the feature without trying to get into a lot of detail.
In the regular Waterfall kind of product development methodology, the Product Management team / person defines a great level of detail for all the features and puts these into the Requirement documents. These are then signed off by the customers (in many of the cases), and then explained to the various teams. In turn, the teams then create design documents, test documents, and do a full traceability matrix from the requirements. This ensures that the requirements are adhered to in great detail, and there is no confusion among the implementation team with respect to the requirements.
So, when a member of the Product Management team starts working as a part of the Scrum team, they are used to the level of detail that they already do in the past. Consider the case where the team has a number of features, and the Product Owner looks at the features, and based on their past record, start breaking down the features into how the screens should look like. In the extreme case, the Product Owner will continue on this line and insist that the team should design the screens and dialogs exactly like how the Product Owner wants it to be, right at the beginning of the cycle.
In Scrum, the Product Owner should take the feature / User Story, and define the User Stories / tasks in such a way that they answer the various queries that the users of the product will have. So, when defining user interactions, these are defined in terms of problems that the users will be looking, not in terms of the screens that will be present in the application. This does not mean that the Product Owner will not look at how the UI of the application should like, it’s just that the UI definition should happen near the relevant Sprint; and in fact, the Product Owner should work with the UI designer attached to the team, and work in advance to get concepts of how the screen should look like.
The difference is that the Product Owner should focus on the ease of use of the application, get feedback on how the workflows can be made more user friendly, and so on. And, since the UI is part of the features that are demoed at the end of the Sprint, there can be more feedback that causes a change in the UI that has been designed earlier. The Product Owner should be ready to modify the UI as and when required.
I reviewed what I have written earlier, and it seems to match what our team does, but seems a bit confusing. Can you comment on how your team works ?

More about the Product Backlog – When and where ?

ashish — Tue, 24 Nov 2009 17:11:10 +0000

In the previous post (link), I had started writing about the Product Backlog, but soon realized that I needed more than one post. So here is Part 2 about the Product Backlog.
Part of the debate about a Product Backlog is about the extent of detail, as well as when should more detail be added. Now, Scrum is all about not adding detailed requirements well ahead of time (Waterfall, anyone?); it is about getting details in when these details are required by the team to start implementing the required user stories. However, if you consider the situation where, for a given Sprint Planning, the top items in the Product Backlog (as optimized by the Product Owner) contains only single statement requests, you do not have enough detail to start work. One can envisage spending a lot of time in the Sprint Planning sessions where the feature needs to be detailed enough so that estimates can be made. However, for the case of user stories where the workflow is complex or needs to be detailed, you need the User Interface Designer to have already spent some time before the team can make estimates and start working on the tasks. For this purpose, you would need the Product Owner to have spent the required time with the UE team so as to have added more details to the user story, and then the User Interface Designer to draw up the required workflows. It could be argued that if the workflow / user story is so complex that it would require so much pre-work, then maybe the user story has not been stated clearly enough. However, for many UI interaction heavy tasks such as portals, shopping carts, etc, it is required that this kind of pre-work be done; although you only need to do it as the relevant Sprint appears closer, as opposed to doing it much earlier. One advantage of doing such pre-work is that several different UI’s can be generated, and user feedback sought from a sample set of users. This helps in ensuring that the final product will be closer to one that customers want.
Further, taking such a approach means that the user story can be refined, and also broken down into several smaller user stories, with the additional advantage that estimation for such tasks can be done with a greater amount of efficiency. One thing to keep in mind is that you need not reach a final detailed UE, instead a UE that is good enough to guide the team can be done upto the Sprint planning, and the UE finalized during the actual Sprint cycle.

Benefits of usability testing

ashish — Thu, 24 Apr 2008 19:15:12 +0000

Why is there such a lot of focus on doing proper usability testing ? Whenever there is any discussion of doing a product and plans are drawn, doing usability testing is deemed as a critical part of the overall plan. What are the benefits of doing usability testing and what can you learn about your product from this process ? Presented below is a list of queries / outcomes / benefits, many of which may seem relevant and others not so relevant:

Are the test participants able to complete the task scenarios successfully? Do the test participants understand the various test scenarios ? If they are not able to understand or frequently ask for directions or seem confused, it implies that there are problems that need to be addressed.

Do participants perform well enough to meet the usability objectives? Supposing the participants are able to move ahead in the flow, the next question is about their performance in the study. Their level of completion, the amount of assistance they required, whether they moved in the workflow the same way that the designers intended, all these are queries that need to be assessed.

How satisfied are participants with the site or application? It is very important to gauge the level of satisfaction of the users with the site / application. Preparing a series of questions during and after the study will allow determination of the satisfaction levels of the users with the overall site / application, as well as individual elements.

What changes are needed to make sure that the site / application will enable more users to perform more successfully? A usability study is an excellent time to find out which is the more user-friendly route for users. In fact, it is very much possible that during the course of a usability study, designs could be reworked in an iterative way to find the one that seems to be the most user-friendly.

Verification of user analysis data: Designs in a lot of cases have been made on the basis of previous user analysis data. Typically, such analysis leads to a lot of data about the workflows that users seem to prefer; however, it is also known that in many cases, users state something based on questions – but these can get modified when they actually see this in operation (also known as ‘users finally get to know what they want when they see it’). Hence, usability studies are a good way of finally verifying the user analysis data.

Validate design guidelines: The usability testing also helps to confirm the various design guidelines that have been established for the project. These guidelines serve to set the basis of the user workflows. An example of some of these are:
* Make links predictable: Links should have the same type of UI and should work in the same way
* Make screens as simple as possible — first screen should have only the most frequently used functions and secondary screens should have optional interactions
* Use graphics minimally — only when necessary, and make graphics meaningful, to indicate where a link goes or what page it deals with; and
* Make the page easy to scan — most people scan the page, picking out individual words or sentences and do not read word-by-word
Now these are general guidelines and may not be applicable for all cases.

Testing allows designers to settle disagreements and differences: Different designers in a team could have multiple opinions and getting usability tests determines which is the one most likely to work. This happens without hurting egos if decisions are made on the basis of user study.

Usability tests can help you understand how real users will use your product, and how the interface could be improved accordingly: Teams developing the product / site can have blinkered visions; getting target segment users brings you close to reality.

Results of testing give the designer ammunition to use in responding to outside attempts to change design based on whims or personal bias: Higher management or experts can have their own opinions and may want a workflow to happen in a certain way, and getting usability results helps defeat such attempts if they are based on personal whims.

Testing saves time and money. Rubin notes that “doing usability testing through the development project allows you to make user-centered changes as you go, before you have so much time and money invested in the project that it makes it difficult to make changes.

Testing is good public relations: It sends a message that the team/company is interested in what the user thinks and needs and can be used very easily for good coverage and to show that the company has done a best effort.

Testing allows the designer to cast a broad net: It helps ensure that the design is good for all users, not just those users who think like you do. Getting a cross section that is diverse is much easier if you are doing a bigger usability study.

In summary, the process can work like this – With the iterative approach, a site prototype can be created, viewed, and evaluated by a small subset of users who identify problems and suggest changes. Once immediate problems are corrected and suggestions are implemented, the site is released to a larger audience, who become part of the design and quality control team by using and evaluating the resources and sharing their feedback with the developers. Usability testing methods, by their very nature, keep the user in the forefront. User testing helped us, the designers, distance ourselves from the product. Rather than focusing on what we thought/liked/needed, we could focus on what the user thinks/likes/needs. What users say they need and want is often substantially disconnected from what they actually need and want when faced with using a product to perform a task. It is for these reasons that the only way to effectively determine what is best for users is to observe users performing tasks with the product of interest.

What is user interface prototyping ?

ashish — Sat, 16 Feb 2008 19:40:39 +0000

A prototype is a semi-functional simulation of the product, and an inexpensive alternative to full technical implementation. Prototyping is an excellent means for generating ideas about how a user interface can be designed, and it helps to evaluate the quality of a solution at an early stage. Prototypes may be created using tools such as paper, white boards, Adobe Illustrator, Photoshop, HTML, Flash, Java or other technologies. The prototype is used to refine the user interface and user experience. Usability tests are often conducted using a User Interface Prototype.
User interface (UI) prototyping is an iterative analysis technique in which users are actively involved in the mocking-up of the UI for a system. UI prototypes have several purposes:
* As an analysis artifact that enables you to explore the problem space with your stakeholders.
* As a requirements artifact to initially envision the system.
* As a design artifact that enables you to explore the solution space of your system.
* A vehicle for you to communicate the possible UI design(s) of your system.
* A potential foundation from which to continue developing the system (if you intend to throw the prototype away and start over from scratch then you don’t need to invest the time writing quality code for your prototype).
In the past, it was very common for the consideration of the user interface to be one of the last steps performed in the System Development Life Cycle. Typically after everything about the system had been analyzed and designed, the user interface was developed. The driving factors behind the interface design tended to be what the programmer felt was a logical, intuitive depiction of the system’s capabilities and processes. When, or if, usability testing was done, it generally occurred after barriers such as coding time and expense were in place that prohibited major revisions.
What users want is for developers to build applications that meet their needs and that are easy to use. Too many developers think that they are artistic geniuses – they do not bother to follow user interface design standards or invest the effort to make their applications usable, instead they mistakenly believe that the important thing is to make the code clever or to use a really interesting color scheme.
A well-designed graphical user interface decreases the user’s learning curve and is able to lessen the user’s mental load when using the application. User interfaces have been shown to impact usability when measured by such criteria as speed, accuracy, number of tasks completed, time to learn how to use the system, frequent of reference to documentation, and subjective measures regarding satisfaction with system and satisfaction with performance.

Why does user interface design fail ?

ashish — Tue, 12 Feb 2008 18:18:36 +0000

Let’s take the scenario of a company striving to make a great product. They believe that they have a good development team, are well connected with potential consumers, and there is a ready market out there. And they are sufficiently knowledgeable that they want to do a cycle of user interface design and spend some amount of time in this process. Everything done, they release the product / web site and wait to see praise and purchases coming in; to their horror, the product does not take off as expected, and support staff get a lot of customer reports about poor interface. Why do cases like these happen ? Well, here are some possible reasons for such a thing happening:

1. A fundamental difference between the way interaction and information experts diverge instead of collaborating. In the case of the company, the interface designer worked in a silo, instead of spending a lot of time with the information workflow expert. While usability is obviously important, it’s far from the only consideration in designing a user experience. There are at least three aspects to sites: information, experience, and interaction – fact (or fiction), form, and function, if you will. User interface gurus tend to focus only on interaction, and the information architecture gurus tend to focus on information – and each tends to overlook the other two areas.

2. No single magic bullet to interface design. Expert literature offers many principles of good interface design, providing helpful guidelines for designers. However, even if every designer in a software development organization was well versed in these design principles, this would not be enough to ensure good interface design. Many of the available design principles are based on experts’ intuitions, rather than on hard data. What may work in one situation would not work in another, and it is for the interface designer to try out the ones that seem most suitable, and then test them out as to their individual benefits. Usually for any given design problem, they will come in direct conflict with each other, and there are no algorithms for making the trade-offs.

3. User interface design is a matter of compromise and tradeoff, for example, there i the need for powerful functionality, but within a simple, clear interface (seems a paradox in most cases). We want ease of use but also ease of learning. We want a system that is flexible but also one that provides good error handling. We strive for consistency across all aspects of the interface, but also to optimize individual operations. The interface designer finds him or herself constantly confronted with these kinds of conflicting goals, and with the expectation that the designer will be able to resolve all of them brilliantly. Well, sometimes these are not resolved.

4. Design by committee: In many cases, maybe to speed things up, or because influential stakeholders feel that they have the pulse of the customer, they get involved in the interface design process. Or many representatives from the team join in. In such cases, the interface designer has to take along all these people, and compromise; sometimes weakening the design.

5. In many many cases, designers operate in a vacuum, with little prior experience and no interaction with potential users to guide them. At best the interface designers are experienced and have learned from feedback from users of earlier systems. Even so, the technology changes so quickly that even experienced designers constantly confront new design possibilities they have no prior experience with, or have to work with changes technical possibilities that they are really not aware about.

6. Taking the interface designer’s work as gospel: The interface designer is not god. Even though the work looks good, it is always good to get the work evaluated by users in the form of usability testing.

7. Inexperienced designers: Just because a person is an interface designer does not automatically mean a high degree of skill in all areas. For example, if a web designer skilled in commercial web sites was asked to develop the interface for a web applet version of a media player, one can be sure that it will take some time to develop the necessary domain experience to be able to judge customer flows.

Poor user interface design can hide even the most powerful and useful Web sites or well engineered products from all but the most advanced and patient users. Developers have to consider seriously the issues of user interface implementation. A poor user interface will mean low usage of the site and its ultimate failure.