Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Backstory

Working on a large project rebuilding a complex web application that currently lags well behind the competitive offerings. Stakeholders are keen to go 'scorched earth' on the approach i.e. lose all (most) old/dated design metaphors in the name of simplicity and user-centricity. Essentially build a new app.

At this stage we have a number of relatively mature personas, detailed scenarios, and a core feature set. We have a high-level value proposition, and some design guidelines roughly based on that.

We also have some "interface inspiration", i.e. some example of existing tools that closely match or required functionality, so that we avoid reinventing the wheel where possible.

My Question

Is there a generally recognized way to move from where we are now to the wireframe stage?

Do we just start throwing stuff down on paper and develop an internal system of iterative feedback?

I've just not been at this stage a of project like this before, and would appreciate any experience-based advice.

share|improve this question
    
Could you kindly elaborate "Detailed Scenarios" and "Feature Set". These can mean slightly different things and involve different deliverables depending on who does them and to what extent. –  Izhaki Sep 9 '13 at 23:02
add comment

3 Answers

up vote 2 down vote accepted

I'm usually all for the "a bit of everything" approach.

Get a handle on some basic navigation: how do you get to those features that are in there?.

Make your first steps on the datamodel. Roughly spec out the kind of workflows the application needs to support. The kind of data it needs to output and the kind of stuff users will need to put in. That will tell you something about the design patterns you can use throughout the application.

All that should get you some information to put down a first visual mockup. Get some artist input to visualize stuff and kickstart your wireframes towards something more concrete.

It kind of depends on the kind of application you're building, but getting navigation and the most key design patterns down will get you off to a good start.

Iterate all that as the features and workflows become more mature. Use your scenarios and personas to inform and validate your design thinking throughout the project.

share|improve this answer
add comment

Yes, start of with navigation flow, headers/footers, any master components that will be used throughout the app. I would also some sort of understanding of the standardization of elements and widgets that will be used throughout the app. From that point, the other details should fall into place based on your research.

share|improve this answer
add comment

Although the answer truly depends on the project, in my case the main input into wireframes is the task models, combined with the content inventory (which is partly derived from the task models).

An Example Diagram of a Task Model

The task models (which I really prefer to call goal models) are experiential and context-free; that is, they show evaluation nodes, and decisions/actions as the connections between them. They are not yet mapped to any system - it's what happens in people's brain.

Then the real challenge is to slice these task models into templates (and the clustering patterns within them). The template scope is decided and evaluated based on a multitude of inputs:

  • Content scale, priority and UB (user/business) rankning
  • Analytics
  • Competitor Benchmarking
  • Consistency with other task models and templates
  • Some general design guidelines (eg, sought interactions vs forced interactions)
  • Etc.

Ideally (and depending on complexity) you have 3-5 design ideas to compare, which are then being evaluated by various means. How much iterations there are (and also how much you go from coarse to fine with the wireframes) depends on the complexity of the system (the more complex the more templates, the more these are related and need to be consistent).

Following this will come IA. But that is the main nut to crack for me - the bridge from task models to wireframes.

Personas are used in the whole process but indirectly rather than directly. For instance, personas can justify the prioritising of content A over content B, but I find it hard to imagine how you leap from a persona directly into a wireframe (unless the persona includes a hi-res photo with the task model printed on the t-shirt).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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