Thursday, May 28, 2009
Paper Prototyping
I love the famous quote by T.S Eliot:
"If I had more time, I would have written a shorter letter"
I think the same applies for UI design. In order to do it right, it takes time, discipline, and many attempts to get it right...
As technical people that are able to implement, we tend go right into implementation and choose to react to ideas and changes as they come without regard to holistic future direction and responsible design. I call this "Christmas Tree Design", where your purpose is to get all the decorations (features) on the tree (product). This is not good design - only experience and discipline will teach you that sometime less it more.
If you start with a high fidelity prototype, you are mentally less apt to change it when new ideas and challenges are realized or discovered. This is why I love paper prototyping and low fidelity design tools like Balsamiq Mockups. You can learn and discover, and iterate on design early and often.
About a year ago, my team embarked on an aggressive new product development project. Our new product would be founded on several key initiatives with the number one goal of being ease of use. But how could we ensure we would create a usable product? Sure we had good ideas, but we needed to ensure that our ideas would work with customers.
We decided our best chance was talking to users, conducting usability tests with and paper prototypes. We had mapped out the entire user experience design and all the screens of our future product on plain paper. Then we took this to a company trade show and sat with customers to test of our new product ideas.
We didn't have any software code written yet, we didn't even have a product name or solid marketing plan yet. But we knew we wanted to reduce the UI refactoring time and to hit the market with a very easy to use product.
We had about 20 customers sit with us one-to-one with our paper prototypes. We asked them to pretend that their pen was a mouse. We gave them several tasks to perform on our paper mockup. We asked them to think aloud, and each time they clicked the mouse, we would place a new paper UI screen on the desk. Once they got the hang of it, they quickly became used to our design. We did this on each customer for about an hour. Then we discussed with them their needs and wants.
We started to notice some usability flaws with our design in some of the users, and realized we need to change some of the UI screens. No problem - because we were using paper, we quickly created alternate screens and scenarios to test more users with. This became an iterative process and by the end we had a very usable and fully tested UI design and workflow. All without writing any code!
A year later we returned back to the trade show, but this time with a fully functioning released product. We tested some of the same designs only this time with the final product. It was a huge hit. We got confirmation that we did indeed deliver on what mattered most to our customers and we continue to hear great things from our customers on how much they like and appreciate the UI and the ease of use of our product.
"If I had more time, I would have written a shorter letter"
I think the same applies for UI design. In order to do it right, it takes time, discipline, and many attempts to get it right...
As technical people that are able to implement, we tend go right into implementation and choose to react to ideas and changes as they come without regard to holistic future direction and responsible design. I call this "Christmas Tree Design", where your purpose is to get all the decorations (features) on the tree (product). This is not good design - only experience and discipline will teach you that sometime less it more.
If you start with a high fidelity prototype, you are mentally less apt to change it when new ideas and challenges are realized or discovered. This is why I love paper prototyping and low fidelity design tools like Balsamiq Mockups. You can learn and discover, and iterate on design early and often.
About a year ago, my team embarked on an aggressive new product development project. Our new product would be founded on several key initiatives with the number one goal of being ease of use. But how could we ensure we would create a usable product? Sure we had good ideas, but we needed to ensure that our ideas would work with customers.
We decided our best chance was talking to users, conducting usability tests with and paper prototypes. We had mapped out the entire user experience design and all the screens of our future product on plain paper. Then we took this to a company trade show and sat with customers to test of our new product ideas.
We didn't have any software code written yet, we didn't even have a product name or solid marketing plan yet. But we knew we wanted to reduce the UI refactoring time and to hit the market with a very easy to use product.
We had about 20 customers sit with us one-to-one with our paper prototypes. We asked them to pretend that their pen was a mouse. We gave them several tasks to perform on our paper mockup. We asked them to think aloud, and each time they clicked the mouse, we would place a new paper UI screen on the desk. Once they got the hang of it, they quickly became used to our design. We did this on each customer for about an hour. Then we discussed with them their needs and wants.
We started to notice some usability flaws with our design in some of the users, and realized we need to change some of the UI screens. No problem - because we were using paper, we quickly created alternate screens and scenarios to test more users with. This became an iterative process and by the end we had a very usable and fully tested UI design and workflow. All without writing any code!
A year later we returned back to the trade show, but this time with a fully functioning released product. We tested some of the same designs only this time with the final product. It was a huge hit. We got confirmation that we did indeed deliver on what mattered most to our customers and we continue to hear great things from our customers on how much they like and appreciate the UI and the ease of use of our product.
Labels: Balsamiq, Design, Paper Prototype, UI, UX
Agile Planning Poker
An important part of being Agile is continuous grooming of the backlog and user story sizing and estimation. Many teams struggle with this.One technique we have adopted is a poker style estimation game.
This is how it works:
Each developer on the team is given a small deck of cards with story point numbers on the back. A user story is presented to the team by the product owner. Then each developer must put one card face down on the table representing their estimate. After all cards are on the table, the cards are turned over. The team discusses any disparity between the high and low card. We play the game again until we converge on the same estimate.
I have found this to be very effective and somewhat fun. We have found that this method makes for much better estimates, and ensures that everyone has a voice on the size of each user story. It engages each of the participant and we have meaningful discussions that remove doubt and assumptions.
Since I run a global team, I have developed a Online version of this game that we use during sprint planning and estimation. I hope to open source this project soon to allow others to take advantage of this powerful estimation technique.
Labels: agile, estiamtion, planning, poker, scrum
Subscribe to Posts [Atom]
