ERGOSIGN Blog

A new case study highlights how ERGOSIGN supported the company CADRZ in the successful redesign of their civil engineering works management application KUBA.

Besides designing for different platforms and contexts (touch, desktop, etc.) the creation of highly reusable WPF templates played a very important role.

The promise of the international universal design award intends to serve as an inspiration for designers and manufacturers so that their creativity, competence and experience can flow into products, architecture and services for everyone - not just the "aged".

You can find more information in our respective case study.

Right in time for the Easter week two new free icons are available for download in our icon shop.

In cooperation with Digitec Vertriebs GmbH and INOSOFT GmbH ERGOSIGN offers a workshop on March 25th on the topic of "Changing Visualization: Innovative technology and modern design - Visualizing the next generation with VisiWin".

More information on the website of the Automatisierungstreff.

• Thursday, 8th of April, 2010
• 2:15 to 3:45 PM
• Missionsstrasse 64a
  Room 04
  Department for Psychology
  University of Basel

There is a new free icon pack in our icon store:

Matching the glossy style of our stock library you can now get free icons for Twitter, iPhone, Business Man and Fill (in the sizes 16px, 24px, 32px, 48px as well as 128px).

Jump over to our free icons in our icon shop...

With more software projects cascading down the waterfall (pun intended), agile software development principles have grown more and more in importance over the last years with the goal to make software development more lightweight and adaptable to ongoing changes (budgetary- and functionality-wise).

As implementing agile techniques for a project has major influences on the way management and development teams are working, it of course also has influences on UCD activities and the way they can be applied during an agile project.

This adaptation varies from project to project to fit the customer’s needs. These adaptations can range from designers working closely together with the development teams on-site to an on-demand designer who receives the requirements from the project teams and delivers the wireframes or screen designs accordingly. This really depends on a couple of factors that need to be decided per project (e.g. product enhancement vs. new development, in-house expertise, co-location or availability of users).

Process Information

Figure 1: Schema of the design and development track working together in parallel.

The agile process requires UCD techniques to scale according to the process. In the available documentation on the internet [cf. Further Reading] and also from our experiences it has proven to be essential, to prepare iterations in advance so that at least a rough GUI sketch is available as a ‘lightweight guideline’ for the iteration to start. This has the big advantage that this can already be used as a basis for discussion within the teams and with the product owner or even for doing paper prototyping with users to validate designs even before a line of code has been written.

The duration of this iteration preparation phase depends on the comprehensiveness of the overall vision that has been established at the beginning of the project because it might heavily influence the design of the UI for the iteration (e.g. should the UI be represented in a dialog or a drawer?).

We would strongly advise to use the “cycle 0 phase” at the beginning of the project to produce a visual representation of the vision on a wireframe basis that can be used as a central theme. Especially if you are working with different teams in parallel this will lower the risk that they will run into consistency issues and in different directions. However, this vision needs to be reviewed frequently to ensure that it is still valid or adapted where necessary.

Composition of Teams

As mentioned before, the composition of teams can vary a lot depending on the project’s circumstances. But the most important thing is that there is a GUI responsible person included in every team.

As can be seen in figure 1, depending on the stage the project is in, there can be quite some tasks that are running in parallel with regard to designing, researching and testing.

Figure 2: User research support group

This can be compensated with a ‘second line’ User research support group (cf. figure 2) that takes the questions from the teams, clarifies the issues with users and reports back to the teams. This way, the support team will also have a good overview about the different UI projects and it can use their connections to the user community to organise some lightweight usability testing.

Design-Scrum-of-Scrums

Additionally, a design-scrum-of-scrums has proven to be very good to keep track of different design solutions within other teams, meaning regular meetings after the teams’ stand-up meetings with the GUI representatives of these teams. It’s a good way to inform the designers about newly built components, layout issues or problems with the overall vision that can then be adapted according to the input of the teams.

UCD deliverables & tasks depending on the level of the project

In some of our projects so far, we have used a wiki as a possibility to store information about the overall vision, the different projects and decisions that have been taken. It can also be used to incrementally build up a collection of guidelines that can be reused for further designs within other releases as soon as certain aspects of the user interface are fixed (e.g. icons, colours, patterns).

The following sections will dig a little deeper into the UCD deliverables depending on the level of the project. 

Project Level

Although users are foreseen to be included or consulted frequently for lots of agile methodologies, it may sometimes be difficult to get day-by-day access to them or one user carries the burden of representing the whole user community which one user cannot sufficiently do.

UCD activities like a user task analysis helps in understanding how users are actually performing their tasks and can help the project team to gather the requirements for the project.

The gathered requirements can then be used to create a first wireframe version of the new tool that can be used to communicate the vision within a company but also to early verify certain UI concepts with users. It should focus on the overall structure and interactions of the user interface. The information represented in the wireframes can then also be used to gradually chunk the overall tool down into pieces for the different releases and iterations. 

Figure 3: Generic example for a high-level mock-up

Release Level

The information provided by the vision wireframes can now be used, adapted and elaborated to find the right scope and requirements for the project on a release level (e.g. “For the first release we would like to have the navigation area being populated and the available data is displayed in the content area”).

Figure 4: Release mock-up with focus on navigation and content area

This visual representation can also help the development teams in estimating their efforts to build such a solution and the product owner to prioritize features. 

Iteration Level

For every iteration of a release, the wireframe can now be broken down into several pieces and be described in more detail.

Figure 5: Iteration Wireframe with additional information

Wireframes on an iteration level should be treated as a way to document design decisions in a lightweight manner. It has proven to be very efficient to print out screenshots and put them on the ‘agile wall’ of the project team. This has served as a great gathering point for discussions on the tool.

When the design is finalised for the iteration, the designer can then invest time in producing the required assets like icons or any other kind of graphics. If decisions are taken that influence the higher-level mock-ups, this should be communicated to the design team and adapted where appropriate.

And of course not to mention the preparation of the next iterations with regards to user research (cf. figure 2) and wireframes (cf. figure 1).

Conclusion

Maybe the main conclusion we gathered within our experiences with agile projects is that there is no exclusive way of conducting an agile project. Both methodologies have to adapt to find the best way of interacting with each other. These adaptations strongly depend on several factors such as product enhancement vs. new development, in-house expertise, co-location or availability of users.

From our point of view, UCD methods such as a user/task analysis at the beginning to gather requirements, creating wireframe mock-ups to validate and test concepts at very early stages and our experiences with testing software at several steps of the project can bring real value to the process of developing usable software in an agile manner.

If you would like to get in contact on how UCD activities can bring value to your project, please don't hesitate to contact us at contact@ergosign.de.

Further reading

http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.html

http://www.devx.com/enterprise/Article/42156/1954

http://www.slideshare.net/LaneHalley/making-sense-of-ucd-and-agile

http://www.boxesandarrows.com/view/bringing-user

Introduction

When Steve Jobs announced the iPad, he emphasized Apple's embracement of a new third segment of devices, right between the smartphone and traditional computer/laptops. The target hereby - at least in the beginning - lies in the home context, in which content such as websites, photos, movies and books is primarily just consumed passively.

From a user interface designer's point of view the iPad as such is particularly interesting in three ways:

• With the iPad Apple sticks to the same interaction paradigm as on the iPhone: Except for the Home button the interface is completely touchbased. However now the size of the iPad's display provides enough screen estate to avoid the frequent collision of controls and artefact happening on iPhone, especially in games.
• The temptation to twist the current passive character of the iPad into more active content producing scenarios is immense. This at the same times raises quite interesting constraints and challenges for the touch-concept. Especially the correct estimation how soon touch-interaction with the device gets inefficient and un-ergonomic for example when entering text, will be crucial.
• In the medium term the iPad can integrate usage scenarios in the home context, that until now were distributed across several devices. This directly inclines tasks such as checking email (previously done e.g. on a Blackberry), surfing the web (previously done e.g. on a laptop), reading ebooks (previously done e.g. on a Kindle) and media consumption (previously done e.g. on a HD-recorder) etc...

Overall the iPad stands representatively for a huge exploitable potential, especially for us user experience designers whose brain cells never stopped buzzing since Steve's keynote.

In the following we sketch two usage scenarios, which highlight the advantages of such an (integrating) tablet in the home context, which might even be shared by multiple family members.

(Disclaimer: Of course we are aware that there were similar devices and concepts before the iPad. But judging from the current media feedback, it is safe to assume that - just like the iPod and the iPhone stand for a fundamental change in the music and smartphone businesses - the iPad will revolutionize the tablet-business.)

Scenario #1: Personalized Radio for Father Homer

Until now Homer turned on his radio every morning to start the day with good tunes mixed with news and the weather update. The only problem is that either the taste of the DJs is questionable or the frequency of news is too low.

With our new radio.app this service can be tailored much better: Countless semantic connections through custom artist-tags, neighbourhoods of shared musical taste, individual news-intervals are just a few benefits to mention.

Besides its light-weight portability the tablet bears a key advantage in this scenario by leveraging its touchbased interaction. The interface scales beautifully with the complexity of the usage context, starting from trivial (Start, Stop) to precise gesturebased navigation through the tag cloud by zoom & pinch. Furthermore different views can be switched through simple swiping in the upper half of the screen.

Scenario #2: Interactive Learning for Daughter Lisa

Lisa perceives the static representations in her physics schoolbooks way too abstract thus extremely boring, which reflects directly into her grades.

With our new learning.app she is now able to view all experiment setups from different perspectives, zoom in and most importantly replay them as movies at any speed.

The advantage of gesture based controls in this scenario is obvious: Besides directly tangible manipulation of the view angle, the level of represented information adapts naturally by zoom & pinch. Furthermore the setup itself can be re-arranged on the screen by dragging its parts just like in real life without any indirect interaction (mouse or keyboard).

Eventually this natural interaction makes the physical laws for Lisa transparent and conclusive. Any error in her setup gets highlighted instantenously both in the calculations (bottom screen half) and in the schema (upper half) via live simulation.

ERGOSIGN proudly supports UXcamp Europe 2010, which takes place on May 29th and 30th in Berlin.

Leveraging the advantages of the contemporary barcamp-principle, designers discuss, collaborate and present hot topics from all UX-related domains.

Tickets are free, all you have to do is register (early) on the barcamp's wiki ...

We look forward to great sessions!

Prof. Dr. Dieter Wallach is holding a presentation today on the topic "HCI: From Theory to Practice and back" at the Informatisches Kolloquium des Hamburger Informatik-Forum e.V.

• Montag, 1. Februar 2010
• 17 Uhr c.t.
• Vogt-Kölln-Str. 30
• Konrad-Zuse-Hörsaal
• Gebäude B