Boxes and Arrows: Comments by Manish Pillewar

Manish Pillewar — Thu, 15 Mar 2007 13:10:25 GMT

Bubbles and the wireframes:
I reckon this level of detailing for the wirefrmes is required when the designer is not present while presenting the concept. Have been working in a constantly changing client scenario, I find it easier to just blurr out the concept details: what section would load, whats on focus and how does it appear etc. The rest is self evident. Normally even for a RIA, the wireframe would be used only to show placeholders and the IA and Navigation concept. Maybe, content at times. A clients development team would definitely catch up on the nature of the UI elements within minutes of the presentation. A Powerpoint low/medium fidelity prototype should be enough to get across the ideas. Else, get it simulated on Visio/asp/etc. I find this level of detail unnecessary when the designer is there to explain it.

Manish Pillewar — Mon, 02 Apr 2007 11:03:37 GMT

The should be some way to undo a vote. I clicked on the offensive option by mistake. Ignore that Afshan. Looking forward to read your article.
Cheers!
Manish

Manish Pillewar — Fri, 07 Jan 2011 19:40:35 GMT

Communication:
This has to be polished to a professional extent. Newbies need to practice clear communication in order to articulate their ideas to the clients at times. Clear and professional communication also helps in defining the exact goal of the UI exercise and helps to eliminate ambiguity. Junior designers need to practice writing professional emails and polish their talk as well.
Subset : Vocabulary:
Again from a professional perspective, designers need to learn the talk. Know and practice using UI jargons, read a lot for the same. Designers need to be armed with examples for every UI design they suggest as well. Clients, often from the business side, need to be given examples they know & UI’s they have seen, to understand things better.
My two cents.

Manish Pillewar — Tue, 31 Jan 2012 14:01:03 GMT

There will always be these two school of thoughts. One that will vouch for HTML prototyping as the best tool to help end users and customers to understand the flows and interactions and the second, which will defy this approach for various reasons. My experience both in Waterfall and Agile has been that it all depends on the luxury of time, money and quality.
In the waterfall process, the designer can spend some time to make the HTML clickable prototypes in sync with the use cases and demonstrate them to the client and users and the internal dev team the concept of the workflows and designs. There is enough time to do so. My experience in Agile and specifically the Inception phases of the project dictates that the best tools are the ones that are the fastest and yet communicate the interaction in the most lucid manner. I am talking about tools as simple as whiteboarding, paper protos, ppt, digital notepads like the DigiMemo 692 etc. These allow for basic interactions to be quickly drawn and agreed upon by the stakeholders. It gives the devs to understand the UI constructs and the BA to plan the functionality asap. Should there be a need to show flows and interactions, tools like Axure help a lot. What you need is a good team of a UI dev and a Visual designer. An UI dev to understand and monitor the designs and the visuals and give his opinion on whats possible and easy to implement. I see these roles differently, though most will disagree, simply from the aspects of time and the mode of thinking- as a UI dev+designer I don’t want my initial design concepts to fall into the trap of ‘what possible’- that which again depends on how much knowledge of the UI dev I possess. This is however not an excuse to not know and understand the basics of HTML/CSS. I recommend that every designer understands the implementation details of the designs. And not just HTML/CSS, but the entire process of development, testing, deployment and release. There are other reasons why not HTML/CSS as others have mentioned-Cost, Color traps, non-reusable code and quickness. If you/re following Agile SDLC, a better approach for gathering feedback would be quick/guerrilla testing and a phased release/betas to the users. Happy Designing!