Humble Design

Here is the Presentation of my session ‘Rapid Prototyping’ at ThoughtWorks XConf, Pune, India

Transcript of the session:

Slide 1 to Slide 4:
Prototyping is a great way to communicate the intent of design both clearly and effectively – helps to flesh out design ideas. test assumptions and gather real time feedback from the users. There are various ways and tools for prototyping. And lot of discussions in the User Experience and Developer community on better ways of prototyping. Even clients are asking for prototypes as they would like to see how the system would be interacting.
But the point is there is no right way to do it. “No right way to do Prototype”. But if aimed well and done properly, a “prototype can answer design questions and communicate design ideas”
Prototyping is about “show me, don’t tell” approach –  its shows people what you mean and dont tell them, as people like to relate to visuals.

Slide 5:
Here are some instances where prototyping is used.
The first one is paper interface to a programmable climate control system
The second one (bottom left) is the paper sketch of Oscilloscope front panel. I didnt knew the meaning of oscilloscope before, but this paper prototype fascinated me… that to what extend we can do paper prototypes. So i digged out on what ‘oscilloscope’ meant. For those who dont know what oscilloscope is. An oscilloscope is a type of electronic test instrument that allows observation of constantly varying signal voltages, One of the most frequent uses of oscilloscope is troubleshooting malfunctioning electronic equipment and it can graphically show signals.
This paper interface was used for usability testing, to test the oscilloscope front panel.
The other 2 prototypes are for iphone and web applications.
I have used these examples to show how we can leverage prototyping in various areas to communicate effectively and also to test design early on to avoid the costly mistakes.
Thats prototype in the nutshell.

Slide 6:
Here I will be talking about “Prototype for web”
As in an agile environment, a prototype should possibly be fast and iterative, and hence this  session is about “Rapid Prototyping”

Slide 7:
The key to Rapid Prototyping is
“Think Big” (the idea/ think of the bigger picture)
“Act Small” (take baby steps – prototype at each stage and share/collabrate with team to gather feedback)
(but) “Scale fast” (thats being iterative, as a result of feedback gathered you need to scale up fast)

Slide 8:
Meanwhile, In an effort “to keep track of the big picture”
“Create a high level vision document” (essentially a sitemap or workflow)

Slide 9:
What you should know for prototyping:

1. Basic design principles – http://www.thefloatingfrog.co.uk/graphic-design/basic-design-principles-explained/
2. Heuristic principles – http://www.useit.com/papers/heuristic/heuristic_list.html
3. Essential controls for web applications (or invent new one)
4. Psychology (I would rather call it Common sense) -you should try to understand the psychology of the user, how the user would possibly interact with the system,how to persuade the user.
5. Contextual Inquiry

Slide 10:
Ways of prototyping:
Prototype is usually divided into lo-fi and hi-fi prototype:
Lofi prototype:
What does it offer?

1. Allows for exploration. (trying out different ideas with bunch of consequences)
2. As it ‘proposes’,  it keeps you away from getting stuck.
3. As its tentative, it allows users to fill in gaps (and the focus is on usability and not on visual design)

Lo-fi support ideation and concept validation, while hi-fi are important for refinement and usability testing.
Lofi is “non-commital”….When we are exploring and validating our divergent design ideas, a lack of commitment is important and beneficial. This allows us to be more flexible in our iterations and, therefore, more creative.
As we start to whittle down our design options and “refine” them, we need to start articulating them in a more realistic manner, so everyone on a product team can participate in the design conversation with the same understanding.
This is why it’s more important in later phases to create Hi-fi prototypes.
So if you want Fundamental fixes to be done early on, lo-fi works best. As you saw in my first example… had we done prototype to validate design we could have avoided the costly mistakes.
While hifi prototype is more specific and it aids in understanding interactions as its effective to see “how a site fits together as a series of connected interactions”

Slide 11:
Tools that we could use for prototypes.
Lofi prototype tools:

1. Paper
2. Balsamiq is a tool which has some pre-defined hand drawn web controls and design which you can use for creating mockups.
3. Html/css
4. Powerpoint

These lo-fi Hand drawn or the unfinished look helps the team and customer to focus on the structure without getting hung up on the visual treatments. And thats why Lo-fi prototype works best during ideation stage

For Hi fi prototypes the tools we could use are:

1. Powerpoint
2. Visual Design tools like photoshop, illustrator and fireworks
3. HTML/css
4. Firebug, a mozilla addon

These are basically used during…”Evolution stage “
The one thing I like about Agile is, it gives space for design to evolve.
High Fidelity prototypes are like an high level vision document. We cannt shun away visual design in favour of UX design. While its true that getting interaction design right requires deep understanding of user research, but looks matter too. (Look at the Apple”) Looks affect usability. Unfortunately an ugly mockup of a brilliant idea is often overlooked. But Looks are just one aspect of designing – you have to think about the whole user experience of an object (here the object we are talking about is web)

Slide 12:
As Issac Pinnock points out that-
“The best sites are those where there is a seamless divide between the look, the content and the experience” – Issac Pinnock
Though it  could be shunned by some, there is real value in moving lo-fi prototype to hifi, so as to test interactivity more accurately.
I will brief upon few ways of Rapid prototyping.

Slide 13 to Slide 16:
HTML prototyping:
This is merely a “consequence of agile development”.
Additional Skills required for this is knowledge of html/css (for layouting) and some javascript/jquery (for modeling interaction, may not be of production quality)
Steps: (for creating HTML prototyping)

1. Place the content – start with content and create a structural foundation with html. key is to prioritize the content and put it in right place.
2. Lay(it)out – with css, structure the layout, here you can experiment using and make basic layout changes with the usage of css property float.
3. Start Styling – add a presentation layer with CSS.. add the colors and basic styling
4. Add extra treats: Adding visual treatements – check the typo and design elements
5. Add a behavioral layer using Javascript/jquery

Slide 17:

Updating: (the changes you could do  to html prototype as the result of feedback from team and stakeholders)

1. topography: with css its quick to try out different fonts. To do this same on ppt prototypes or on image would be tedious.
2. layout: you could tweak the layout with css, as the layout is mostly driven by css… this is a possibility
3. adding rounded corners: with the advent of css3 even this is easy.
4. color/design elements: with little helpof photoshop or without it, this task would be easier too and with the advent of css3

Slide 18:
As in case of Hi-fi prototype, html prototyping has its limitations:
Limitations:

1. “You tend to limit your thought process.”
2. “Extra work upfront” – This process may work for some projects where you can afford to buy some time for hifi prototype during initial stages.
3. “For complex design this could be time consuming and” downright “difficult “

Slide 19:
But there are some good takeaways of html prototyping
Takeaways:

1. “Easy to test and validate” In my opinion its much more efficient & effective to validate design and test interactions.
2. “Build an interactive pattern library” It helps to  build out an interactive pattern library, which means that you need not build prototype for every screen or interaction, but instead create a pattern library as reference for developers. It might require some tweaking but its much more rapid way to get the work done.
3. “Could be used for production too” as  the html/css is already built in.

Slide 20:
Example of firebug prototype:
On the left side, it is like a requirement documents, which could be interpretated differently by different people. And on the right side, I have used a prototype and annotated it to explain the design. There would be less need for clarification and also less rework in this case. This is a small example to show how prototype allows you to see the “big picture” in one view, while with documentation you have it read it all to get the “big picture”.
In our usual requirements-driven design and development process, we often dont include designers in the requirement writing process which often result in rewrites of the requirements. But the point is if designers who prototype are included, it helps to catch mistakes early in the design process. the early you catch the mistake, the lower the cost to fix it.

Slide 21 to Silde 23:
Firebug -for rapid prototyping on minor changes to the existing application.

Slide 24:
I find that the most feasible way to prototype is to take an…
Intermediate step:
While you need not use the full-on HTML/CSS approach, but you can embed prototypes (in the form of images) in HMTL so that it can be displayed in web browser. This would be useful to test your design and interactions in early stages.
For instance, I had to design a website for a retail outlet, and the homepage was the face of the customers business, it was there brand. So the homepage design involved a lot dynamics in it      And I did a paper prototype- visual design, again paper prototype -visual design in each iteration.But for the subsequent pages and the product pages , I went straight to html prototyping as the dynamics were a bit low.
This approach worked pretty well for me. So, you need to choose the right tool for the right purpose, and see what suits you and your project the best.

Slide 25:

I would end this session, by highlighting that “Prototype is”

1. “Not just for designers, its for everyone” in the team and for all stages of development,
2. its just you have to
   “Use Right tool for the Right Job”
3. For developers and Business Analysts, the next time you are asked by product owners to implement a design try to
   “Validate the design, through prototyping” before implementing and share/collabrate with the team to validate the prototype – on the basis of design, technical feasibility and business value.
4. In the end its also
   “one of the way towards creating a culture of user experience” in our organisationPrototyping is a great way to communicate the intent of design both clearly and effectively – helps to flesh out design ideas. test assumptions and gather real time feedback from the users.