datastation
software suite for prostheses, orthoses and mobility solutions
client:
project lead:
jürgen spangl
design team:
lukasz bertoli,
aleix inglès elias,
rudolf greger,
tom haberfellner,
georg lauteren,
christian rukower,
jürgen spangl
seven applications for different tasks, with different user interfaces and differing software architectures for use by medical technicians in the selection, production and fitting of prostheses, orthoses and mobility solutions. the aim was to achieve optimal usability as well as an appearance that emphasizes that the components of the software suite belong together. our well proven interaction design methodology formed the basis for the success of the project.
the results of the great team work between Otto Bock and GP are impressive. the effort paid off. the feedback from the market: unanimous and overwhelming.
background
the purpose of the seven applications is to support the medical technicians with the fabrication of the socket, selection, ordering and adjustment of components of the prosthesis, orthoses and mobility solutions. for example, for a leg prosthesis the scenario would roughly be as follows: the technician takes specific measurements of the patient and two photographs of the limb. based on this data, the software computes and visualizes a 3d model of the individual socket. the medical technician now reviews and optimizes the result. the 3d data is then sent to Otto Bock for the fabrication of a thermoplastic test socket. in addition to the socket, all necessary components for the prosthesis can be selected and ordered with the software. this selection process is very complex, because it has to fulfil many constraints, such as functionality of the knee joint and foot, compatibility of different parts and fitting within a certain height. a typical leg prosthesis would consist of about 12 components out of a catalogue of roughly 20,000 parts. once the prosthesis is delivered and built together some of the knee joints [the microprocessor controlled ones, e.g. the c-leg] have to be configured with the software according to the needs of the patient.
for upper extremity prosthetics myoelectric prostheses are possible. those prostheses are electrically powered and driven by electrical impulses transmitted by muscle contractions. the software helps the medical technician measuring the electrical impulses as well as supporting her with the selection of the prosthesis.
»datastation is one of our most important interfaces to our partners. among those are prosthetists, therapists, patients and doctors. they use different applications in different ways. their professional education background is diverse. GP designpartners managed to find approaches, which are flexible to meet the different requirements of the specific groups. an intuitive interface was created, which still allows a high flexibility. GP designpartners impressed by their professional approach. it took them only an amazing short time, until they were able to understand our complex field of work and they were able to contribute with intelligent and creative solutions.
they were the anchor point in an interdisciplinary and international team and were able to support from the very first idea up to implementation and finalization of the product.«
di dr. hans dietl
chief technology officer
user research — the importance of being earnest
as is the case with many of our projects, the persona method and the method of user research were new to our customer. the user research, interviews and workshops with all the project stakeholders proved to be fundamental for both us and the client in gathering an understanding of the different aspects of the project. the user base ranged from people who hardly ever use the computer to experts, who adjust every single parameter of the prosthesis to get the maximum level of comfort for the patient, and the interface has to work for all of them, including language and cultural distinctions. we were able to directly talk to users and observe them in several medical workshops in europe, and to conduct phone interviews with medical technicians in the usa.
the research uncovered important new facts. one example: in contrast to the intended usage of the new software, the medical technicians don't use a computer in the presence of the patient. instead, they collect the information on their customized paper forms, which more or less all have the same layout. all patient data is collected throughout the day and then transferred to the computer either by the medical technician himself or by an administrative assistant in the evening. this was completely new to the whole project team. the old version was designed to be used directly in the presence of the patient.
we summarized all this information in scenarios.
over the course of a few workshops in which we incorporated the feedback of many team members, we reached an agreement with Otto Bock on the personas and their characteristics. the personas were printed and laminated, so that they are not easily tucked away in a project folder and thus never looked at again. each department got its own deck of personas. from that point on the personas were brought to every meeting and the overview sheet was put in the centre of the table. this encouraged us all to use the names or nicknames — all of our personas have meaningful nicknames, such as »the meister« or »the one-man show« — of the personas and to integrate them into our meetings.
the knowledge gained in the user research was thereby easily shared among the team members throughout the project.
from initial ideas to the final product
because of the wide range of different applications we had to bring onto one platform, we had to deal with two different kinds of problems:
- finding a metaphor for bringing all applications together.
- finding concepts for many detailed problems — for example: 3d manipulation, component selection for a prosthesis, setting marks on photos, capturing 3d data, or adjusting a technical device while in operation on a patient.
we will now focus on a single functionality — the component selection — to explain our approach:
the component selection has to fulfil many constraints, such as functionality of the knee joint and foot, compatibility of different parts and fitting within a certain height. to master the complexity of the interdependencies of the components, the previous version was handled by a wizard-like process. the problem with this type of approach was that the users did not like it, as it did not match the selection process they were used to: usually the medical technicians start with a certain knee joint or a foot. this selection is often influenced by the patient, who has preferences towards a certain type, and by the social insurance companies, which only allow for a certain budget.
during the initial meetings with the client and engineers we discussed these problems — and a game we played as children came to mind: zoo mix max. the game became our first prototype. with zoo mix max we were able to quickly explore our idea of an open selection process. the selection of any component at any time was possible. by simply simulating the mouse click with a finger tap and then pushing the relevant row into position so that the selected part becomes a part of the »prosthesis«, we gained a better understanding of how the idea could work.
we developed this approach further and built a simple prototype. the prototype shows that the selection process could be started with any component, and that any component could be changed at any time. with each selection the new possibilities are computed and shown [suggested ones, possible ones, and impossible ones]. we also wanted the system to provide a reason why certain components are impossible or not practical to use. we even made it possible for the medical technicians to select impractical components — they are the experts and thus know what they are doing. of course, this could then result in some already selected parts becoming impractical, but others would be suggested to solve this situation. we believed in a system which supports the exploration of different options.
this early prototype was an excellent way to present our concept. it allowed all members involved to provide input and feedback. at this stage of the project we also did not know how our approach would work in detail. but with the presentation of an early prototype we were able to get viable feedback at an early stage.
based on the findings of the paper prototypes for the overall concept [which we usability-tested internally] and on the functional prototype for the component selection, we built the first version of an overall prototype to run the first usability tests with friendly users. the prototype included the general workflow through a job: creation of new patients, selecting and setting up different jobs, input of dimensions, visualization and manipulation of the 3d model, component selection and ordering.
in general we got good feedback from the usability tests, but also discovered many issues — some of which we did not expect at all. the users especially liked the exploratory element of the selection process, but were not yet convinced by some of the details. but it was still unclear if our approach would work technically and for the users if the whole range of about 20,000 parts was included in the selection process — rather than just the small fraction we put into the prototype. this was addressed in the next version of the prototype.
the results from the usability tests were again very positive. the remaining issues were tackled directly in the project documentation. with this prototype we finally convinced the engineers that the concept was actually technically possible. when we, with — at best — rudimentary programming skills were able to implement a solution which not only worked, but also performed well, it had to be easy for them to do it even better.
get it built
»good, even great, design is meaningless unless it gets built.«
alan cooper in »the inmates are running the asylum: why high tech products drive us crazy and how to restore the sanity«
coming up with a good design is only one part of a successful project. even more important is that the design actually reaches the users. our driver in every project: to make the project a team effort and to get everyone involved in the design of the product. at the same time, this also helps us to ensure that our concepts are implementable.
in addition, this kind of holistic approach demands that we document the designs in such a way that they can be quickly implemented by the engineers.
we documented the interaction design as closely as possible to the actual product in the form of pixel accurate screenshots, flows accompanied by functional specifications to cover the behaviour and functionality, and an interaction design style guide. in addition, the latest prototype was used by the engineers as a living specification for the product. in our opinion, the right combination of those artefacts is important, as any single one, when taken alone, cannot demonstrate the richness of the interaction design in detail.
the engineers did an excellent job transferring the concepts into a working application.
good products demand a holistic approach, where all of the team is involved in the different stages of the project. bringing all stakeholders and their opinions together is often not an easy task. we are happy that we not only were the interaction designers, but often also acted as a catalyst among the parties involved.
functional specifications
functional specifications describe the functionality and interaction concepts and are based on the interaction design style guide. elements are specified in detail in their respective context of use. they define the interaction and its implications for every element and describe what happens in case of an error.
interaction design style guide
the interaction design style guide, also known as the user interface style guide, specifies guiding principles for the interaction elements used, their application and arrangement, as well as the general look & feel. it is based on the corporate identity style guide of the company and the general interface guidelines on which the application is running.
flows
flows cover the details and exceptions, such as error handling, of a product. the syntax used in the flows is defined as per the needs of the project and in agreement with the engineers. flows are useful for both designers and engineers. for designers, they act as a tool for reflection in later stages, when it is time to decide on the details. for engineers, they are a part of the specifications.
pixel accurate screens
pixel accurate screens represent the static information of the design. it is the responsibility of the designer to ensure that the screens are pixel accurate to remove any ambiguity.
