Tag Info

Hot answers tagged

11

I know there's an accepted answer, and I usually do quite agree with Michael, but still this does bug my mind for two days. As a developer, I hated the Apple HIG It just didn't tell me what to do, how to do things in practice. The Windows Guideline was felt as "empty", but it could be that it did because it seemed, on Windows, actually noone follows them. ...


11

For prototypes I'd say that you need to get to the level of detail where you are able to explain and illustrate the functionality in a way that is easy to understand. However, it is also of major importance that no-one believes your prototype to be a finished (or nearly finished) product. In that case you run the risk that your customer either thinks that ...


11

I'm with @Michael Lai, and think they're a great tool to have in your bag for the right case. What they can help you with: Understanding the client As a UI/UX designer you often come into new environments, sometimes very complex ones. User journeys can help you understand processes that might be way out of your field of knowledge, by allowing your client ...


8

Where appropriate - I've often liked the infographic 3D style user journeys as they really key into the visuals and real world perception - see example on Wireframes Magazine and also linked article An introduction to user journeys on Boxes and Arrows. I also love this snapshot on flikr by user tgod from the LUX redesign project (not sure if I should ...


8

As with many of the UX deliverables, it depends on what you believe the best way to communicate the information to your audience is. This is also a debate going around about personas and how useful they are to the design process. In my opinion, I generally try to create some sort of 'user journey' as a way of working out all the different things that a user ...


6

The reason why we do prototypes is to convey ideas/concepts/solutions that can't be conveyed through showing static screens. I always use the rule that whenever you want to give a feel or an understanding of the flow in your application/web service you should do prototypes. It is with the prototypes that you can simulate how something might feel like. For ...


6

The nature of your deliverables honestly depends on the scope of the project, the work you're doing, and what kind of client you're dealing with. The biggest challenge you have to face is determining what the client expects and then providing them with that (or adjusting their expectations where necessary). For instance, a colleague of mine recently created ...


6

Example Style Guides For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes ...


6

One of my mentors said that you will never die of a bad presentation. So relax, take your time, and practice. :) You followed a process to create the design. You identified pain points, user goals, issues with the existing design. Walk them through the highlights of that process. I find that summarizing the work gets me relaxed and makes the presentation ...


5

I'd have to point you to this BBC Internet Blog post for an excellent reference. This blog post describes the technology strategy the BBC Future Media department is using to evolve from a relational content model and static publishing framework towards a fully dynamic semantic publishing (DSP) architecture. You will need to define and describe a set of ...


4

Is it reasonable to update the technical specification every time changes are made during the development of the project? Short answer: Yes, it's worth the time to update the specs. More context: Technical specification ≠ documentation, but often there is no documentation at all. So if changes are made during the course of long project there is ...


3

I think this could be handled by providing simple affordance. If it looks like a generic link, it will be a link. If it looks like a button, it will be a button. If you want to increase the affordance in your Mega Menu, you may want to consider: A down-pointing arrow next to each horizontal menu item or a right-pointing arrow next to a vertical menu ...


3

I have had a couple of user journey examples included in the last talk I gave entitled Some Things You Can't Wireframe. You'll find the slides, and below that the links to the websites where I got the examples from - including the Lego Wheel, Home Theatre and Service Design. Hope it's useful! Here's one of the screenshots: the Lego Wheel for a flight from ...


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 ...


3

I find it to hard to give a clear recommendation as we do not know as much as you do. But I could imagine the following options might help. Finally you have to decide which suits you best. First describe the general page once - put in a placeholder for each module or elements which has different states according to the user type. After you described the ...


3

I have found the journey maps effective in following ways: Time spent - I normally map timings of varous user steps. This help quantify and identify possible inefficiencies Repeated task - I did a study of the Washington DC Metro Rail ticket purchase process, and I found that the user had to calculate the amount of money multiple times due to the gap ...


3

For me, the value has decreased with the popularity of customer experience, instead I find myself referring to an Experience Map if the project permits. I find the lines are blurred between User Journey and Experience Maps as they're similar models albeit the latter tends to be more visual. Adaptive path have a helpful article that explains their ...


2

"Which deliverables are important for the client to see and how far do you develop them? " A deliverable that fully communicates the interaction and intent of the UI is important. You develop it as far as you need to to accomplish that. The specifics of that answer are entirely dependent on the project and the client. As an aside, this is what Agile ...


2

The answer might also depend on what kind of prototype you were trying to deliver. If it was just for one (static) web page, you would be left with many options e.g. design tools such as Photoshop or Illustrator, and even hand-drawn sketches. For a more complete / complex story that might include multiple-state web pages, user flows, and/or customized user ...


2

I tried Axure and a few other tools to make prototypes and came to the conclusion that prototypes were an utter waste of time with a terrible ROI. I went back to a much more successful method, using PowerPoint to make storybaords. I use the slide master to paste a vanilla blank of my app..the skin as wallpaper. Then I have a few controls saved on a final ...


2

Show off your enthusiasm for this type of work. List groups and communities you participate in, posts you've written, links to proof-of-concepts you've done on your own, scan in "your napkins" and put them up if they show off your thought processes, link to answers you've supplied on listServes,.. and so forth.


2

It depends on the exact nature of the deliverable. I'm puzzled that you'd distribute them in paper full stop, actually, unless you've a client who insist that submissions for tender go through a paper process (not that rare in the public sector, actually). But the paper size depends on the exact reading context. Is this one person who's going to be reading ...


2

There's no fixed number or amount of time. The goal of personas is to create a model of people in your demographic so that your team and client can focus on, communicate about, and refer back to this representation when making decisions. Ultimately, personas are an aspect of a process called mental modeling. The goal of mental modeling is to understand your ...


2

I use BasecampHQ for this sort of situation: create overall projects and projects for each sprint follow message threads within a project and attach documents to messages messages are usually copied to email - and can be replied from email get a collective view of all the files attached to that project collaboratively edit documentation via the writeboards ...


2

If you're using Axure, then you already have access to publish to Axure Share. The annotations and notes are still readily available on the page and anyone can access it at any time. When you update the wires and republish, it uses the same url - so it a bit like a living document. I use this all the time and it's incredibly useful for sharing ideas/specs ...


2

Overseas development is often code for 'poor' development. I've found no amount of style guides will resolve those issues. But that's a different topic. As for what works, it varies wildly from team to team, project to project. As we build more complex web applications, with more complex interactions and the like, I'm finding the better path to go down is ...


2

online Wiki with the spec Look into using a 'component library'. They take time to set up initially, but can streamline projects down the road. The idea is to document individual elements. For instance, you may have a design pattern for a search field. You'd describe this pattern in the component library, add some visuals, and, ideally, maybe even have ...


2

For the "Lean" part of this: dividing the design documentation into: Style Guide - Always up to date Individual Designs - Not kept up to date after they have served their purpose. Wiki or Confluence is great for documentation since you can link from the designs to the Style Guide (and also in the case of using Confluence and Jira, link development ...


2

I have experience of three different tools for creating style guides: Confluence The first style guide I implemented was built using Confluence. It was more a design pattern library, containing patterns and best practices for the most common UI design problems. Each pattern contained an example image, description how it works and why it should be used, and ...



Only top voted, non community-wiki answers of a minimum length are eligible