Hot answers tagged

14

Yes, they do. Low fidelity tends to get people to focus on the higher level aspects of the mockups, like the overall layout and concept. While with high fidelity mockups people tend to focus on the lower level details like "this should be two pixels to the left", or "this needs to be a different shade". That is one of the reasons that I recommend ...


8

A/B testing is about optimisation. Mockups and user testing are about insight. User testing (even with a small sample set) will help give you insights into what potential problem areas may be so that you can find ways of improving them. This should be your goal, not trying to optimise a design. A/B testing, needs large sample sets to make any conclusion ...


6

For quick and efficient mockup testing, I recommend using any program that can link 2 images and Silverback for recording the users sessions. Build a small user panel (5-7 people) - more if you can... Write up a short scenario which tells your users what they should accomplish before testing the flows. Build 2 versions of the same flow using your mockups ...


6

Considerations Employers are more focused on your problem solving skills and creativity in achieving this rather than the content of your wireframes. But this is no blanket rule: Problems that require solutions in terms of information architecture and information design will deserve extra attention in this area as long as the copy or labels used ...


6

"Low fidelity prototype" refers to a prototype i.e sketchy and incomplete. You basically collect data analyze & check the feasibility at the early stage. Whereas "high fidelity prototype" refers to a fully functional prototype wherein you provide click-through interfaces. In simple terms, it's the actual product that will be shipped. You should always ...


6

MyDraft - https://mydraft.cc/ - https://github.com/mydraft-cc/ui - Can be used online, written in typescript, react and redux, uses font awesome library for icons. I found it by searching on github for wireframe tool repos and then looking at those with lots of stars.


5

It seems like you have two issues: Verifying/understanding user requirements; and Convincing your team that testing is a good idea. Verifying/understanding user requirements When trying to understand or verify user requirements, I try to stay from using any type of mockup or prototype. In this stage, I try to understand the problem not attempt a solution. ...


5

I employ a technique I call "MVW" Minimum Viable Wireframes : Put the least amount of effort into the wireframe that conveys the design and purpose to it's intended audience. If a napkin sketch gets the point across, great. If it's a whiteboard sketch that you and the developer make together and take a picture of, go with it. (My favorite) Both of ...


5

The primary goal of the mockup is to show concept, not the frame. So long screen looks more holistic, rather than separated pieces. You can depict the "above the fold" line to show clearly what users will see on entering the screen. Image source


5

I've seen examples of cardboard or wooden devices with paper prototypes which slide through slots at each edge. Transport for London (via ComputerWeekly): And ironPhone, a custom made sketch preview tool (via dribbble) I've also had a lot of success using images in an interactive digital mockup that allows the user to scroll to the bottom if necessary.


5

It's also helpful to consider what kind of fidelity you're referring to so that you don't get into the wrong kind of mixed fidelity. "High fidelity" often mistakenly refers to only the graphic design aspect, i.e. static screens and screen states that look more or less production-realistic and not obvious mock ups. The problem is that when evaluating ...


4

Mockflow.com and Moqups.com both offer the ability to share with others and edit in real time. You can also provide read-only access to anyone or export your ui mockup as a .pdf. Mockflow seems to be more developed and stable, but I personally prefer the user experience of moqups.


4

I swear that I will repeatedly tell users that nothing is guaranteed to actually appear in the final product, and that it may end up looking nothing like the mockups Tried that many times, it simply doesn't work that way. Problem #1: Users will have false sense of progress - There is nothing you can say or do to explain to your customers that what you are ...


4

This is tedious Yep. It sure is. And, sadly, is typical in a lot of organizations. The solution, ideally, is to stop creating so much documentation. UX should be about improving things, not publishing copious amounts of PDFs that get sent to some lost vault inside of SharePoint. Frustratingly, UX teams--especially in large corporations--tend to be ...


4

This may sound funny but I am not joking... Make crummy looking mockups. Find some design software that lets you render your ideas as imitation pencil-drawings, preferably one with multiple-colored pencils available. Use that software to render any UI elements and dummy text in pale grays, so that they are clearly inferior to the Clean Bold Dark Type ...


4

I normally pack it respecting the tasks or sub-tasks, according to the priority order from the product owner/teamlead (more urgent first), so that when developers are going into the sprint, they have all they need for the feature they are about to start working on. Normally for me it's 2 to 5 screens per sprint per team, so if you are working with two ...


4

Using real copy instead of placeholder text is another venue to display your creativity. Even if you are not a copywriter, it shows that you are capable of delivering more than just wireframes and comps. It also better describes the work you were doing, and leaves less guesswork for the person reviewing the work. There are times it is appropriate to use ...


4

What is the main task of your users? Is it necessary for them to see the information of the different widgets at the same time? Also, how is determined for each widget which top 4 to show (since they can view more)? If your users will focus only on one part of the dashboard, according to their own tasks (like 'Finances and Billing') I would chose a minimal ...


4

This one probably needs a little more context to give an helpful answer. To me, saying "over 100 mocks" already sounds a weird request: how do you know how many? What documentation / brief do you have? Where do the number comes from? For the sake of the argument I tried to do some math: 100 mocks in 4 days means 25 per day; suppose we have an eight hour ...


3

System Usability Scale questions I think that I would like to use this system frequently. I found the system unnecessarily complex. I thought the system was easy to use. I think that I would need the support of a technical person to be able to use this system. I found the various functions in this system were well integrated. I thought ...


3

The purpose of mockups is to communicate ideas. Depending on the stage of development you select the appropriate fidelity. During the initial phases you are debating different features and layout options in your design, a low fidelity prototype easily captures this (animations/transitions are not the kind of features I am talking about here). You can add ...


3

I can only provide you with my experience having experimented with many different types of stimulus for users. The original statement about getting the right fidelity is spot on. In general it is possible to get similair results from end users in most situations but if it's too far from the final result you run a risk of some users not really getting it. ...


3

Here are a few research papers comparing the feedback provided in response to interacting with low-fidelity and high-fidelity prototypes. In these papers, 'fidelity' refers to visual design fidelity and not one of the other 4 dimensions useful for describing prototype fidelity. This paper reports on the comparison of paper and computer prototypes for a ...


3

It's better to include real copy. I say this because: It will give the people context for your design. It will help them understand why you chose to design the interface and interactions the way you did. The copy is an important part of the user experience. If you demonstrate that you are a skilled writer, that is a benefit to you. See this link for more ...


3

The point of Lorem Ipsum is to try and not distract the audience from other things (design, site structure, etc.) when content is not the main focus. If you want to demonstrate your copy writing abilities than definitely include it. If your writing is so bad that it'll distract from demonstrating your other capabilities (visual design, interaction design, ...


3

I think the use of lorem ipsum depends on the type of wireframes you work on. When I look at a UX designer's portfolio my main questions are "what sort of problems have they worked on?" and "what were the thought process in solving the problems?" I don't think that using lorem ipsum is bad in any way provided it's warranted. Wireframes ...


3

Lorem Ipsum distract the clients from design mock-ups. It leads them to ask on why their site if filled with an unknown, foreign language. It has often created confusion between the designer, developer and the copywriter or content provider. It even gets pushed live sometimes without anyone noticing. Using Lorem Ipsum is a way half-heatedly go about the ...


3

This isn't one tool but two - Dropbox and Github. Here's instructions of how somebody else set it up: http://alexcican.com/post/guide-hosting-website-dropbox-github/ Edit: Zurb's Notable feels like the best tool out there for collaborating on HTML mockups: http://www.zurb.com/notable


3

Common requirements: I have identified common requirements/patterns for the "login form" concepts I came across. Use OAuth/OpenID for authentication have the login on overlay: removes the background image issue as it is often hard to have a responsive background that does not get ugly overlaid by the login box in some resolutions username input label - ...


3

It's a designer's job to solve real world problems. The idea is to develop a portfolio containing case studies that demonstrate your ability to work through and solve problems. Finding the problem With a lack of a real problem you should create one. To get your problem you can find a product (or product marketing materials) with design that you believe to ...


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