5

From an IA/UX designer perspective, what do you think about HiFi wireframe storyboard for Web applications, instead of a classic deliverables approach?

I have read a very good documentation about Mobile Design Information Architecture deliverables:

http://www.slideshare.net/bryanrieger/modeling-the-mobile-user-experience

In resume, he proposes "wireframes storyboards" (or sketches storyboards), based on views, states and events, as a whole deliverable project, instead of classic ones, based on lots of different techniques like:

  • Site Maps (navigation design)
  • User process/task flow (interaction design)
  • wireframe page description layout (information and interface design)
  • UI page workflow (navigation and interaction design)
  • Design pattern (interaction design)

For mobile design it really looks great, because with just one technique (storyboard), you can cover all the previous techniques. You don't need to create, for instance, a user task flow map, because you just has to follow the storyboard. Or a SiteMap, because again, the storyboard provides all the necessary information.

What do you think about storyboarding for Web applications? Could be used after sketching section where stakeholders and designers agreed the approach? Could even tools like Balsamiq, keynote Kungfu or UX Prototyping be used instead of deliverables?

Improve this question
7
  • 3
    HiFi wireframes don't seem to pay off unless it is for an investor presentation. The visual design aspects are distracting from the interaction aspects.
    – Andy Fleming
    Commented Mar 18, 2012 at 2:28
  • Welcome to UX.Stack! What you're asking is rather out of the scope of Stack Exchange. Even if you were to reword the question asking for use cases of the technique, storyboarding is a very common-place approach that is applicable at any stage of UX design.
    – dnbrv
    Commented Mar 18, 2012 at 3:13
  • @DesignerGuy. Actually, i don't understand why HiFi wireframes distracts from interaction aspects.It continues being a black&white blueprint with no art design (.psd), but only information about interaction, navigation or content design.Something you directly apply from Sketching stage, but where the product owner can see something 'real', and developers can have a specification as an extra for their backlog.
    – user1106811
    Commented Mar 18, 2012 at 22:29
  • @DesignerGuy is right x1000. You might have a superb experience designed but your colleagues/client cannot help but look at the design and not the architecture. This is why tools like Balsamiq purposefully have a hand-drawn style for their elements.
    – Max
    Commented May 15, 2012 at 3:54
  • @user1106811 - Max is right. Doing "some" design makes it even worse. Because you've theoretically started to design, but even the littlest bit of design will prompt critiquing. Personally, in the wireframe part of the process, I strictly don't "design". It inevitably will slow down the process in an unproductive way.
    – Andy Fleming
    Commented May 15, 2012 at 18:22

4 Answers 4

Reset to default
3

Overall, I feel that the individual tools are more versatile.

I think the more you mix into one deliverable, the harder it is to focus on the individual aspects. Like the example of HiFi wireframes that I mentioned in my comments, clients often get distracted by the wrong details.

The other problem is that I feel like a storyboard falls more in line with a use case. How can a storyboard account for all of the different possible paths a user could take? It might be a great way to illustrate and overall experience, but not a strong way to evaluate those individual aspects of the project. There is a time and place for that though. I think a high quality storyboard can speak volumes to investors.

For day-to-day decision makers I think that the individual tools are more effective. It creates a solid foundation and framework where changes can't be made lightly. Each decision you make should be purposeful and should have the support of those individual tools. It will keep things on track.

Improve this answer
2

Stick to individual artifacts (User Goals, Site Maps, Annotated Wireframes) and make sure they are consistent across all of them, without being redundant.

The "just enough information" premise keeps your artifacts focused, and with the right amount of supporting fact.

Improve this answer
1

For early ideation, I think storyboarding for mobile, or any project with changing states, is a great idea.

But... I don't think he's proposing storyboards at all. He's proposing building wireframes with interactivity using the Processing language.

Which is fine, but it seems wasteful. You could learn HTML, CSS, and jQuery, and do exactly the same thing, plus you'd have code you could use in the final project, and have skills that are useful for something other than creating interactive wireframes.

That's exactly how I do it. Build clickable, interactive wireframe in HTML5/CSS3/jQuery(jQ Mobile if it's a mobile projects). Works great.

Improve this answer
4
  • @J.Jeffryes.thanks for your response. But i was refering to WireFlows, like this one: nform.com/tradingcards/wireflow, but using tools like invisionapp.com, that lets you just link (lowfi or hifi) wireframes or prototypes (.psd) through buttons events. From my point of view, interactive prototypes (HTML+CSS+jQuery) only works if the wireframe stage is finished, and you are on the "art design" stage (photoshop). Is not a huge effort and investing time constantly changing thinks in HTML?
    – user1106811
    Commented Mar 19, 2012 at 13:35
  • 2
    I'm a former print designer (from before there was a web), and I used to do everything in photoshop, then chop it appart into HTML because it would be faster. But once I became truly proficient in HTML, I discovered it was much faster to build the wireframes in HTML. Changing a line of text in HTML is faster than changing that line in Photoshop, and with CSS you can change a class and alter the appearance of dozens of elements, where in PS usually you'd have to change each state separately.
    – J. Jeffryes
    Commented Mar 20, 2012 at 12:58
  • Definitely much better to build interactive prototypes. Use a CSS framework like blueprint and you'll get a layout together in no time. And you'll spend a lot less time documenting or explaining what something would do if it wasn't a static image.
    – Undistraction
    Commented Apr 5, 2012 at 13:48
  • "Is not a huge effort and investing time constantly changing thinks in HTML?" It's no more of an effort than it is to constantly change things in Visio. Or Axure.
    – DA01
    Commented May 15, 2012 at 22:06
0

EDIT:

I agree with Bryan's presentation. Wireframes and Prototypes are terrible client deliverables as they are bloated and nearly always out of date/sync.

I don't know if I agree that the XML based storyboard system is any different, though. Perhaps it is. I'd need more details.

My gut reaction, though, is if you're going to go hi-fi, go all the way. Actually work in the medium it will be built in. If it's a web app, actually built the HTML CSS and JS required to communicate the interactions.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.