Learn Software Development » User

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.

Different types of end-user metrics

ashish — Sun, 16 Nov 2008 11:41:41 +0000

Typically, metrics in software are meant to mean something related to capturing lines of code, number of defects, or some other measurements related to software quality. User metrics is something entirely different, meant to try to capture data relating to the customers usage of the software. The advantages that you get out of such capturing end user software metrics are:
1. Capturing such metrics helps in validating design principles: Say both product management and engineering feel that the implementation of a particular feature is the defined way to do it, but after looking at user-functionality usage metrics, you find that the usage of the feature is lower, then some re-thinking needs to happen.
2. Helps in capturing problem areas: Suppose there is logic in the system that it reports every time that the application gets into an unstable or incorrect position (for example, if there are some parameters being passed to a functional that was deemed unlikely), then you know that there is additional work to be done in these areas.
3. Finding priority areas: Reviewing user-functionality usage graphs can be help you find which are the functions that are the most used of the application. Sometimes, product teams get surprised when they review the usage metrics for their applications. Supposed you are the team for a photo editing software, and you expect that some of the editing tools would be the most popular; and then you find to your surprise that a simple tool such as a Quick Fix tool is the most popular. Such data helps you determine the areas that are important to users, and what you need to fcous on.
4. Determining poorly designed workflows: If you have metrics in place that determine how long a users takes to complete a particular workflow as well as how many people have abandoned the workflow, you get an idea of how simple vs. badly designed a workflow is. A poor workflow would leave users spending far more time on that workflow, or even pressing ‘Cancel’ to leave the function in frustration.
5. Determining which features to drop. Sometimes there are features in a software that are built with a lot of hope, and do not live up to the promise. In addition, there are other features that have outlived their usefulness and need to be dropped as part of a periodic cleaning of the application. Such end user metrics can help a lot in determining the features that need to be removed.
6. Determining license usage. In the case of softwares that are available as floating licenses or as enterprise softwares, capturing of usage information helps in determining whether the pricing of such software is correct. Such metrics also help in determining whether there is any violation of licensing terms.

User Interface Prototyping Tools

ashish — Thu, 06 Mar 2008 10:43:58 +0000

There are plenty of prototyping tools available out there, both free and purchasable. All of them have their adherents, and detractors; I was looking for some, so I went out and tried to find out tools that people use. If you use any of these tools and have some comments, please do put a comment.
One criteria that I saw on a forum, that seemed to be good:
1) Create interactive elements with visual design developed within tool or ability to bring in externally developed imagery
2) Ability to place elements quickly on screen (WYSIWYG)
3) Ability to assign / program interactivity actions
4) Prototype can operate on Wintel machine with minimum of required support infrastructure (i.e., .exe would be fine for us). This can be extrapolated to mean a tool that works on the desired platform.

A listing of tools:

Visio: Website. Available for a starting price of $260. User Description: The reason why Visio is the favourite prototyping tool of many interaction designers is because of its ready-made interface objects, you can drag-and-drop onto pages and its ability to link pages together and export them as web pages. But what distinguishes Visio from other prototyping tools is its use of layered backgrounds.

Flash: Website. Costs $699. Description: Visually adjust shape properties on the stage with smart shape drawing tools, create precise vector illustrations with the new Pen tool inspired by Adobe Illustrator, paste illustrations from Illustrator CS3 into Flash CS3, and more.

Adobe AIR: Website. Freely available. Adobe AIR uses the same proven, cost-effective technologies used to build web applications, so development and deployment is rapid and low risk. You can use your existing web development resources to create engaging, branded applications that run on all major desktop operating systems.

MS Expression Suite: Website. Trial available at this link. Pricing for the Expression Studio is $599. Description: Microsoft Expression Design is a professional illustration and graphic design tool that lets you build compelling elements for both Web and desktop application user interfaces.

Axure – Website. This is a paid product, currently costing $589 per license. Description: Axure RP enables application designers to create wireframes, flow diagrams, prototypes, and specifications for applications and web sites faster and easier than creating static mockups with their current tools

Fireworks: Website. Available for $299. Description: Prototype interactive layouts for websites and rich Internet applications. Export website prototypes to Adobe Dreamweaver and RIA prototypes to Adobe Flex.

OmniGraffe: Website. Standard version at $100 and professional for $200. Description: Need a diagram, process chart, quick page-layout, website mockup or graphic design? OmniGraffle 5 handles all of these in one award-winning application. We’re not just a pretty interface, however. There’s plenty of power under the hood to make all your diagramming and design fast and easy, with the ability to customize and tweak every aspect of your work.

iRise: Website. This is a very high priced product, with solutions starting at $5,000.

Powerpoint: Website. Costs $229 per license. Powerpoint allows you to prepare fairly rich mockups.

DENIM – Website. Freely available. Description: DENIM is a system that helps web site designers in the early stages of design. DENIM supports sketching input, allows design at different refinement levels, and unifies the levels through zooming.

Illustrator: Website. Costs $599 per license. Description: Discover new ways to experiment with color; work faster with new drawing tools and controls; and produce artwork for print, web, mobile, and motion designs.

Director: Website. Costs $999 per license. Description: Adobe Director 11 and Adobe Shockwave Player software help you create and publish compelling interactive games, demos, prototypes, simulations, and eLearning courses for the web, Mac and Windows desktops, DVDs, and CDs. Integrate virtually any major file format, including video created with Adobe Flash software and native 3D content, for the greatest return on your creativity.

Photoshop: Website. Available starting from $649. Photoshop is a leading tool for generating graphics, an integral part of image manipulation used for prototyping.

EasyPrototype: Website. Price $69 only. Description: Unlike traditional drawing tools or code-centric prototyping tools that require as much effort to use as building the real thing, EasyPrototype works with your existing techniques such as paper sketches, Photoshop mockups, or whiteboard sessions so you can produce a dynamic prototype in just minutes.

Napkin: Website. Freely available. Description: The idea is to create a complete look and feel that can be used while the thing is not done which will convey an emotional message to match the rational one. As pieces of the work are done, the GUI for those pieces can be switched to use the “formal” (final) look and feel, allowing someone looking at demos over time to see the progress of the entire system reflected in the expression of the GUI. Over time, several folks have just liked the thing and wanted to use it for non-provisional GUI’s. Sometimes this is because the application itself seems to match the theme, such as a brainstorming tool. And sometimes it’s just that it looks fun.

Smart Draw: Website. Price $197 per license. Description: With SmartDraw anyone can create great looking business graphics in minutes, not hours. SmartDraw anticipates your needs—giving you pre-drawn templates, automating design, and making it easy to turn your information into brilliant illustrations fast.

Petra: Website. Priced at 300 Euros. Description: Petra is analytical modeling tool, which will help you to:
- exactly specify client requirements
- easily produce prototype of the final application
- reduce the number of errors in detailed functional specifications
- Improve the quality of specifications for ensuing project phases

LovelyCharts: Website. Available in Beta right now. Description: An online diagramming application built using Flex. Create flowcharts, sitemaps, wireframes, organization charts, etc.

DesignerVista: Website. Personal: $79.99 & Commercial: $129.99. Description: DesignerVista is a rapid GUI design Tool for Project Managers, Business Analysts, Consultants, Usability Engineers, Team Leads and Software Developers. DesignerVista Software helps you to create GUI design, GUI Mockup design, GUI screenshot, GUI prototype and Simple Web Page prototype design. You can save all the designs as HTML files for easy distribution.

MockupScreens: Description. Costs $79 per license. Description: MockupScreens helps you to sketch screen mockups of your application and organize them in scenarios. With MockupScreens you can experiment interactively with your clients, and quickly visualize scenarios of your application, even before the coding has started.

User interface prototyping tips and techniques

ashish — Thu, 06 Mar 2008 08:24:59 +0000

I was looking for some tips on how best to optimize user interface prototyping when I came across some great tips at Ambysoft as well as the IBM Developer site. A UI prototyping process is very important for teams that want to take their product development process as close to being successfu as possible, and has numerous development cycle benefits as well. So, here’s these tips:

1. Work with the real users: There is no way to get around this. You need to get the actual end users involved, they are the ones who have the most at stake.
2. Use prototyping tool: It makes sense to spend some money in a prototyping tool that will allow the team to quickly put together screens and not have to put too much effort in getting this done. It is not necessary to develop good code, since a prototype is not recommended to substitute for final code.
3. Get users to work with the prototype: Unless all the stakeholders get involved with the prototype, they will not be able to see how the proposed system will meet their needs. Further, this will help in generating some useful feedback.
4. A good understanding of the requirements and the business: Since a prototype is meant to provide an overall idea of the final solution, the people building the prototype need to have a good understanding of the business logic and requirements.
5. The code is throwaway: It has been a standard understanding of the prototyping process that all code generated through the prototyping business is throwaway, and nobody should fall in love with the prototype and code that they would consider using the prototype as a development platform. Don’t spend unnecessary effort to make the code beautiful.
6. Not everything can be simple: When building a prototype, there is a temptation to try and simplify things in order to present a good picture. However, users know how complex their workflows can be, and it would be a mistake to not show them the contour of the final proposed workflow. It also helps in tweaking the complex workflow solution by getting good feedback from them.
7. Don’t get over-ambitious: Just because a feature is easily built via a prototype, does not mean that it should be put it. A prototype should not have features that are not part of the schedule, as that might lead to expectations that would certainly not be fulfilled.
8. Expert help in design: Building a prototype is not easy. It needs people who are experienced; for optimum benefits, if necessary, bring in expert help for this design.
9. Make users aware of what a prototype is / is not: Many end users are not so aware of software practices, and if that is the case, then they should be educated about the purpose of a prototype. There should be no expectation that a prototype is a product and just needs a bit more work.
10. Don’t use the prototype for making decision: The use of terms make a lot of difference to users. If you build a good workflow, but use very specific terms, users are likely to factor in the terms (for example, if there are alternate ways of completing a task) as a way of how the work flow will happen. It is better to have the terms be generic.