wireframes & usability

This blog is intended to cover many different things around Usability and Wireframing and some related stuff we do at pidoco. In some situations we were hesitating with publishing things of our daily work at pidoco that are rather technical and might be a little misplaced in here. Therefore, we started the blog funky code a while ago with some of our fellow students from Hasso Plattner Institute where we can publish all our ideas about web development, working at a startup, project management, or what just comes to our mind.

Today I published the second part of a double blog post on JavaScript testing (first part) and how automated tests can be integrated into a continuous integration server (second part). If you think that such topics could be of interest to you, please feel free to bookmark http://fun.kyco.de or add it to your favorite feed reader. If that is not the case, you won’t be bothered with these things in here anymore.

We have been using pidoco ourselves for years. But right now it is getting more interesting since we are working on the next version of pidoco.

In our usual development cycle of three weeks we concentrated on many smaller improvements and little features that help you prototype faster. With the next version we want to implement bigger improvements like adding more structure to the repository and editor, allowing for easier reusing of smaller components within your prototypes, or increasing the flexibility regarding the interactions that you can model with pidoco. This will include the suggestions that we received through our uservoice forum or that were mentioned in our support chat.

Making such big steps will be a nice challenge that we are facing. Currently, we are developing a prototype of the final version that is supposed to include all changes we would like to do. After some initial brainstorming a while ago, Tino started to create the prototype. And he surprised me with some very creative elements, like the little boxes with a ‘V’ inside, which are menus with just one top level entry. They act as simple hover menus, very similar to our current context menu.

Having this initial prototype, we invited some few people to remote usability tests. They were asked by Tino to do some simple tasks, mainly navigating through the given dummy prototype. (Now it’s getting recursive…) Since we used our own tool, we did not have to travel to Frankfurt am Main or Hamburg to meet the people for one hour of test. The complete session was recorded, including all mouse and keyboard interaction and the voice of both Tino and the test participant. That enabled me to review the test sessions, making notes, and collecting all the ideas that arose throughout the tests.

With the notes I spent most of this week in modifying the prototype, applying some simple ideas from the tests, and thinking of solutions for issues we realized during the tests. Following will be an internal review with our team and, possibly in the course of the next two weeks, a further round of remote tests. Until now I’m quite happy how everything worked together. Conducting a test with no setup time, handing over the prototype to different people to work on without any hassle, being able to describe many ideas in the prototype without too much work.

Once we think the concept is kind of finished, the real challenge will start. We do not want to lock our doors for two years and implement the next version in one step. We’d rather like to cut the concept down into manageable pieces that we can implement in a short period of time. Usually, we tried to deploy a new version every third week. This time we might have to break with this rule, but my hope is that we can do most things within 6 weeks (two sprints) or at most 9 weeks, which makes a new version at least every second month. That said, let’s see how it will be in reality. I’ll write some updates every now and then…

Now back to my prototype.

Wow!

That is all I can say about the awesome feedback we got after the UXcamp Europe taking place a week ago.

To give you an idea:

• @elreiss: “UXcamp Europe in Berlin was a SMASH success. Thanks to the fab organizers for making this happen. And keep it open and dynamic!”
• http://twitpic.com/1sh7mw: “Ranjeet Kumar came from India to #uxce10 and says it was a best conference he ever attended (other were paid).”
• Hilko Holweg (maczarr.de) “Das Camp zählt zu den besten, die ich bisher besucht habe.” [The Camp is among the best I ever attended.]

During the closing session on Sunday some were suggesting to have the UXcamp take place either twice a year or make it 4 days long. Well, this might be a little too much for us to organize, but maybe there are others out there who want to do a camp themselves. We’d love to support you in that, so please speak up!

One thing we should not forget is that we only set the infrastructure for the weekend, but the participants filled it with live. Therefore, we have to thank for 57 great sessions (Saturday and Sunday). You can find many of the presentations on slideshare, where we even were a featured event! Many people helped us at either serving coffee all the time or taking care of the cloakroom, which we couldn’t have done ourselves. So, a big THANK YOU to all the 400 people who came to Adlershof to share this weekend with us.

About a third, maybe even more people were traveling a long way since they are not living in Germany. Some were even coming from different continents! We are really happy that we were able to welcome you in Berlin. In my opinion it is quite exceptional that so many people traveled that far just for a BarCamp.

When meeting people after the camp a lot are asking me: “You are doing it next year as well, don’t you?” Well, we have not yet talked about that. It is quite time consuming to organize a BarCamp for 400 people. On the other hand, I have the impression that if we won’t do it again, people might get angry with us and stop talking to us. We’ll let you know…

In this blog post I will show you a cool application that I have worked on outside Pidoco. Some of you might be familiar with using modeling tools. For example if you are a software developer, chances are you have to design architecture diagrams from time to time. Or if you are at a big company, you might have seen one of these complicated process models that explain how your business works. If that’s the case and you use this kind of software, the processWave.org Editor might make your work a lot faster and more convenient.

The processWave.org Editor is a fully collaborative modeling application that lets you create technical diagrams with several people at the same time. All changes that you or others make to the diagram are automatically synced between all participants in real-time – just as you know it from the Pidoco Prototype Creator. It is written as an extension to Google Wave, a powerful new collaboration platform from Google, that helps you create all sorts of documents and artifacts with multiple people very quickly. If you did not have the chance to give Wave a try yet, let me explain how it works: You start a new Wave, an artifact which is often described as “equal parts conversation and document”. You then invite the other people to that Wave to let them participate. And with a click on a toolbar button you add our editor to the document, and start modeling. A typical use case is shown in this video. The cool thing is that you can use Wave’s powerful conversation capabilities to discuss the model while you create it.

To try out the editor yourself, visit http://www.processwave.org – it is free and open source. We currently support modeling in different languages from the areas of software and process modeling, such as the Unified Modeling Language, Petri nets, Business Process Modeling Notation or Event-driven process chains. The work was done by my bachelor’s project team at Hasso Plattner Institute, the place where I study when I am not developing server components of pidoco’s Prototype Creator. Google actually liked our work so much that they invited us to demo it in a talk at Google’s biggest developer conference, Google I/O in San Francisco.

It is just two days until our second UXcamp will take off with the warm up party. The badges are already printed and prepared, 11kg of coffee arrived last week, lanyards and t-shirts arrived today. We are just preparing the session grid and after having a look at the session proposals we hopefully have enough rooms for all the sessions. I can’t help it but I have the urgent feeling that we might have forgotten something. But I guess that is a necessary feeling two days before a big event!

Today we also signed the last sponsoring contract. We are very pleased with having so many sponsors supporting the UXcamp. Without them we would not be able to host such an event and make it free to the participants. Oh, and talking about participants: it was a pleasure to read all the countries on the badges where people are coming from. We have several attendees coming from overseas! In addition, we recognized some pidoco users on the participants list. It would be a pleasure to get to know you in person, so please approach us during the camp.

Hm, still thinking that I forgot something… Anyway, see you on Friday at Volksbar or Saturday morning.

Do you use wireframes in your interface design projects? If so, you may have found yourself debating just how detailed your wireframes should be. In this article I shall explore the concept of wireframe fidelity and how wireframing affects the usability of a user interface in software and/or website design. Deciding which level of fidelity in your wireframes would be most advantageous to you and your project can be pivotal in ensuring success. Experts are still debating the distinctions of wireframe fidelity and whether high or low fidelity is the way to go. In the following paragraphs I will go through the differences in wireframe fidelity and the benefits they carry.

Why use Wireframe Prototypes?

When designing websites or software applications paying attention to a great interface design is key, since the graphical user interface is the part of your software that users see first and use to interact with it. In order to achieve a great interface design, the use of wireframes during the design phase has become a valued method. A wireframe (sometimes referred to as website wireframe, software wireframe or application wireframe) is a visual representation of the projected content and structure of a graphical user interface and is an essential step on the way to a great interface design. It is easily understood by all stakeholders and can serve as communication aid. Much like an architect’s blueprint plans wireframes are an invaluable tool when creating software or websites with a solid foundation. In the same vein, they should be used long before the first bricks (or programming code in this case) are set.

Further Considerations of Using Wireframes.

Wireframes allow a project’s stakeholders to have a vision of what to strive for and are particularly useful in the collaborative process as they ensure that team members can easily understand a software concept and can keep track of a project’s workflow. Popular use cases for wireframes include improving usability through early user tests, involving non-technical key stakeholders early on in the development process, or communicating with developers and designers for planning purposes. The level of detail in a wireframe prototype is referred to as wireframe fidelity and can be in either of two main guises: low fidelity or high fidelity. (Some even distinguish three types, including medium fidelity wireframes.) Knowing which fidelity to employ is of crucial importance as the investment in creating them in terms of time, cost and expertise required varies tremendously.

What are Low Fidelity Wireframes?

Low fidelity wireframes are wireframes that focus on the essentials of a user interface: layout, structure, Information Architecture –  and not graphic design! Low fidelity wireframes evolved onto computer screens from rapid paper prototyping wireframes which emerged in the mid 1980s to become a popular Blue Chip company tool by the mid 1990s. Rapid paper prototyping involved the creation of rough sketches (often drawn by hand) of graphical user interfaces as prototypes of software applications to visualize and test usability long before the coding process began.

Example of a low-fidelity wireframe

What is an example of using Low Fidelity Wireframes?

A real life example of successful paper prototyping stems from the mid-90s when e-commerce was beginning to take off and Priceline.com was introducing a service that allowed consumers to submit a bid for a plane ticket along with a credit card. How could they convince users to trust their credit-card details to an as-yet-unknown website? Paper prototyping showed the team that their initial design would have been a failure, allowing them to correct the problems before launching the site. They also discovered that users didn’t need some of the hard-to-implement features they had included. Paper is a readily available resource, but not easy to change or adapt. Hence, nowadays, digital solutions like “digital paper prototyping” with specialized wireframing software are often used in iterative processes as they tend to be more efficient.

What are the benefits of using Low Fidelity Wireframes?

Low fidelity wireframes have many benefits. By eschewing many cosmetic factors they are relatively inexpensive and quick to create or alter. This allows for collaboration as suggestions and refinements can quickly be added to a number of variations very cheaply. Furthermore, low fidelity wireframes are useful in gathering great feedback because their rather rough appearance makes it clear to viewers that they are talking about a draft that is easy to change, rather than an almost finished product, thus inviting honest and unrestrained feedback. In addition, the lower level of detail allows you to focus on fundamental usability issues of your product. When using low fidelity wireframes for usability tests, testers can also give you qualitative feedback that really focuses on usability rather than being distracted by, say, the color of the fonts used. Yet, some critics caution that the level of abstraction may be difficult for inexperienced users. Once usability has been tested and polished, beautiful designs may be added onto a solid foundation that maximizes user experience.

Here you can find an interesting article on sketched wireframes.

What are High Fidelity Wireframes?

High fidelity wireframes (often referred to simply as high-fidelity prototypes) are very close in design to the true representation of the final user interface design. As such, they tend to include slick and polished design features and even go as far as simulating in much detail an application’s workflow or even logic. Despite pixel-perfect good looks a high fidelity wireframe remains but a prototype, however crisp it may look and feel. Due to their high level of detail, high fidelity wireframes tend to be more costly to create and usually take much more time to compose. They may also require more experience, sometimes even technical expertise, and can hinder the feedback process as testers or clients may be distracted by design features rather than focusing on usability. In addition, test users as well as clients may be more hesitant to critique a design done by a professional, which looks like it would require a significant amount of time to change. Fears that such changes may result in higher project costs are not uncommon and may skew feedback, which makes it very important to explain the purpose and method used in creating high fidelity wireframes before soliciting feedback. Advocates of high-fidelity wireframes find that aside from running usability tests, they enable quicker understanding of decision makers.

An examle of a high-fidelity wireframe.

What are the benefits of High Fidelity Wireframes?

On the positive side, high fidelity wireframes share many of the same advantages with low fidelity wireframes in general but have their own benefits in particular. High fidelity wireframes are usually used in addition to low fidelity wireframes, and after the latter have been used to resolve the most impactful and fundamental usability or interface design problems of an application. Being eye-catching and less costly to create than full-fledged applications, high fidelity wireframes can be used to impress clients who have to sign off on a concept quickly. Since they tend to require less programming knowledge than coded prototypes, high fidelity wireframe prototypes can be composed by users with limited programming knowledge. As they are closer in design to the final product, clients can quickly understand the final look and feel of an application without extensive verbal explanations. The high level of detail reduces the amount of abstraction required by non-technical stakeholders, which – depending on personal experience – may be important in some scenarios. In terms of your development team, high fidelity wireframes allow you to collectively bring an interface to life. This helps in keeping a project’s budget manageable which in turn further satisfies clients. Whether or not high fidelity wireframes are necessary or beneficial depends on the particular project at hand and your goal in using them. One should think about the costs and the benefits of creating detailed high fidelity wireframes beforehand. Sometimes, it turns out that it is faster to go from low fidelity wireframes to programmed code directly.

Which type of Wireframe should one use?

As can be seen from the short portrait above, each type of wireframe has its own advantages. It is often not an “either or“ decision which type of wireframe to use. Instead, both types are useful for different purposes and can be used consecutively in a project. It really depends on the goal or use case at hand and the budget of a project. Yet, if you have to choose one type, the low-fidelity wireframe tends to offer a better cost-benefit ratio as it is quick to create and sufficient to resolve the most urgent usability issues in user interface design which may be the most decisive factor affecting the success of your software. Or you could try “real wireframes” – low-fidelity wireframes augmented with some graphic design elements that help a user who is not familiar with the project understand the wireframe more quickly despite its abstractions.

What fidelity do you prefer in your prototypes?

More on when to use low vs. high fidelity:

http://www.uxmatters.com/mt/archives/2007/03/wireframing-with-patterns.php

http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing

A nice slide show on wireframes:

http://www.slideshare.net/piksels/wireframes-and-interaction-design-documents-presentation

It’s no secret that globalization is upon us; and it’s also no secret that diversity adds to the culture, creativity, and competitiveness of globally operating businesses. We are happy to welcome two new members in our growing team who bring with them international experience and lots of fresh ideas: Carmen from the United States and Abba from Uganda have joined Pidoco’s marketing team and will be working together with the rest of the team to create educational and marketing materials. We wish both of them a great start at Pidoco: Welcome to our team!

Pidoco is committed to diversity. With our new team members we are proud to add yet two more countries to our “portfolio”, which by now includes Vietnam, France, Uganda, the U.S., and – you’ve guessed it: Germany. And we hope that we will continue to diversify our growing team in order to infuse our work atmosphere with new perspectives and unique ideas.

When managing a software project, a lot of the time goes into specifying what the software should do and what it should look like. Once the specification is written it is transformed into many small tasks that have to be assigned to different people working on this project. Designers have to develop some shiny screens, developers have to write the code in behind, maybe the UI has to be localized into several languages, just to name some. However, we all know that there is no project where the specification doesn’t have to be adjusted to new requirements. At this point many project try to adapt some facets of Scrum or other iterative approaches to keep the project manageable.

To date, there are many different tools available that support the project manager in handling all this, one of them is plan.io. We at pidoco use plan.io for quite a while right now and are really happy with it. Since we also use pidoco to create wireframes that represent the major part of our specification, it would be nice to have some kind of integration between the two systems. Having the prototype in the plan.io wiki where you can write some explaining texts around, but at the same time being able to click through the prototype to feel the intended interactions, would be great. In addition, when people comment the prototype using our review feature, most of the times it results in new tasks that we have to do in the next iteration.

From now on this becomes reality. We have developed a small plan.io app that integrates pidoco prototypes with the wiki with one click. In addition, there is a list of all discussions to the prototype, where each of the discussions can be transformed into a new task. On top of that we put all the discussions into the plan.io activity stream, which you can grab the RSS feed and get regular updates of new comments to your prototype. In order to try our plan.io app you need to have both a pidoco and a plan.io account, which you can both test for free.

As already mentioned above, there are plenty of tools out there and you are probably using a different one. However, if you let us know which one, it should be easy to integrate pidoco with your tool as well. While developing the plan.io app we also started developing an API, which we plan to publish soon, for those who would like to write their own integration. More on this is coming soon.

The previous week, I posted part Two of this article.

Tools Which Facilitate (partially) Synchronous Remote Usability Testing:

Here I will be listing some of the tools which in some way would aid in conducting Synchronous Remote Usability testing. Most of the tools will only fulfill some of the requirements listed previously or only implement partially the methodologies above.

Online Conferencing Systems:
These tools allow screen-sharing and remote control of mouse movements and the keyboard.

• Cisco Systems WebEx
• Microsoft NetMeeting
• Yuuguu

Although those tools allow you to observe and control tests sessions they come with a few flaws:

• Test-users are required to install the client software on their own system
• Firewalls may block the software (5% of test-users experience this problem)
• Real-time amendments of the prototype is not possible
• The moderator can’t use his machine for other tasks whilst conducting a test (making notes is not possible)
• Latency problems
• Test-user can not work on a familiar desktop environment

Screen Capture Software:
These programs allow virtual recording of the test-users screen. Test sessions can be recorded and stored but hardware configurations are often insufficient which leads to lagged test results.

• Camtasia by TechSmith
• Cam Studio
• iQuick Screen Capture

Video Conferencing Tools:
Video conferencing tools (Skype, MSN Messenger etc.) allow the moderator and test-user to communicate via live audio&video feeds. The downside is that the client software needs to be installed on both system. Also specific testing of prototypes is not possible and would require additional software which use-up additional bandwidth and system memory.

Presentation Softwares:
MS PowerPoint is a great tool for static presentations, is however limited in it’s collaboration and sharing features.

Video Editing Tools:
You can also create video snippets of your presentations ( MS MovieMaker, Adobe Premiere etc.) but it is a lot of hassle and will surely put you off quickly.

Online Questionaires:
Online questionnaires created with Google Form or Surveymonkey are great applications for getting quantitative feedback on your product. It is however difficult to organize and match the feedback to the right user and test session.

Since this overview on incomplete tools for Synchronous Remote Usability Testing tools could go on forever, I do not wish to withhold the solution for you guys!
A little self-promotion will follow:

pidoco° Usability Suite:
The pidoco° usability suite is an online, web-based collaborative platform which allows to create, share and test prototypes in an instance. It is a tool which combines rapid prototyping of fully interactive prototypes and has powerful collaboration features:

• Prototype Creator (creates realistic & fully functional prototypes via drag&drop)
• Reviewer (allows asynchronous work-flow and feedback collection)
• Remote Usability Tester (Synchronous Remote Usability Testing with screen-sharing, live audio-feed and mouse-tracking)

Conclusion: 

It is possible to conduct user tests at an early stage. The aim for every company is to deliver their product on time and with the least hassle possible. Every year thousands of agencies spend a fortune on running all sorts of tests and still deliver products with flaws which need later amendments. The problem is that early-on, qualitative feedback is needed yet often not achieved due to budget limitations.

Technology allows us to connect to connect to people around the globe, so why not use this opportunity to run usability test session online. It will save us the cost of travel, give the test-user the comfort of staying in his home or at his workplace and create a greener world for all of us!

This weekend we added two new features to the pidoco Prototype Creator: colors and permalinks. From now on you can choose the border and fill color for rectangles and ellipses to highlight certain areas of your prototype. We also added a semi transparent grey filling which you may use to create overlays and modal dialog boxes, similar to what you see on the screenshot.

For the second new feature we slightly modified the invitation dialog and added a new feature to the invite menu entry. In this new dialog you get three links, one points to a png image, one to the sketched html, and the third to the plain html version of your prototype. You can choose the page they will point to and copy paste the link into your wiki or send these links via chat to your colleagues.