Design case

Client context

It was Maia`s month and 13 people were sitting in a meeting room in Germany thinking how to change the paradigm from request-response to event driven. Our customer started in early 90`s with solutions for document and printing apps and evolved to corporate output management dedicated to companies optimization of administrative work. Their biggest customers have more then 20.0000 printers and different administration and print management rules. Within the last years a new architecture was gradually adopted for the application portfolio provided to the end customers and now it was time for the UI to follow suite.

Approach

While we had previously had done work for this customer, this was a new department so we had to first listen, understand the challenge, think ahead together with them customers and create a future-oriented software solution. Therefore a team of 3 (architecture, ux and delivery team lead) traveled to get to know the problem at hand and people trying to solve it at face. We had a new top notch UX process and we were eager to prove its value.
Due to the good collaboration and engagement of the stakeholder representatives with the cross technical capabilities, facilitated by valuable agile practices, at the end of the day we already had a good definition of the challenge to be addressed and first proposal for the solution design.

The focus was to build a web experience served by REST services that not only replaced the old java applet based GUI (with Angular) but expanded with event driven management and monitoring (ELK stack) capabilities. It had to provide end users with easier access and intuitive experience even for large volume jobs. Knowing the target, the following days proceeded by defining interaction models and personas as part of the proposed realization strategy for the recommended digital version. Before the end of the week we had a functioning composition of interactive and static concepts that enabled visualization driven feedback. We incorporated the preliminary feedback and corroborated the brand identity into the graphic design and style guide and signed-off the UX/UI design phase with the delivery of the static markup towards the development team and phase.
We felt accomplished, the customer was happy and was looking excited to see it realized, and the process was proven.

Outcome

While the initial phase already felt good, engaged with the right expertise and process driving already valuable results, the completion felt even better.

Within a couple of months the customer was already using the new web application. The end users found it intuitive and efficient, and the administrators were happy of the capability to integrate multiple endpoint information from the servers, into a central administration console that facilitated multiple levels of administration and monitoring capabilities while preserving the much needed ability to seamlessly deliver incremental updates as requested by the ever changing end customer context.

Development case

Client context

Late in the afternoon, 2 weeks before the main holiday season we get a skype call from one of the main business development managers with whom we had a previously great collaboration on a corporate healthcare driven project. His new mission as a product owner, building a coordinated care-disease prevention centre to help people with lifestyle-related illnesses. Though, what really sparked our tech imagination was his idea of building in a WhatsApp like experience for the individual healthcare.

Approach

We assembled a bootcamp workshop team representing business analysis, engineering and architecture and travelled to customer office in Germany to get a better understanding of the context.

Our product owner is really an enthusiastic guy with great ideas and always driven by possibilities. We join his energy driven flows of ideas and start pruning the product tree. He is under pressure from the business so he has to quickly shape and deliver a functional walking skeleton that can validate ideas and convince the stakeholders upon their holiday is over. As this is a multiple platform audience targeted product we decide to go on with Ionic on the mobile development and Angular on the web. Building a prototype fast is essential so we make use of all readily available technical platforms from Google Firebase to reusable Angular models in order to favour quick validation of those functional flows assumed to be generating critical feedback instead on task completion.

One week and several technical investigates later we`re fully engaged with a team of 6 using agile sprint development into building the prototype that would confirm the feasibility of the solution estimated to meet both business wishes and IT capabilities.

Outcome

When the summer was over, business engaged with prospect customers to validate the business case and market access as well as defining the MVP feature short-list. We continued developing additional complementary flows and secured prototype integration with UX designs and style guide so that we could constantly feed working units of functionality to the business.
The most rewarding moment came from one customer meeting where one of the prospect customer leaders said that the product in its early development phase looks more fit and finished then any of their product ever was.

Consultancy case

Client context

Through our constant focus on helping people succeed in their customer assignment we are building deep relationships that span across projects and even company context. This is how at one point, we were asked by one of the most exigent head of development that we worked with, now the owner of a small IT company, to support growing the business and service portfolio. The original idea was simple, he had a previous positive experience from working with us nearshore and wanted to recreate that in the new context even though none of his team members previously worked in a distributed agile team.

Approach

Initially people were rather reluctant in the proposed agile nearshore model, as some project specifics, typically very intense and short, were indeed challenging. These were both challenges on the agile and the nearshore model, therefore we started with in-person workshops for building up some initial trust in the models before going too much or too fast forward. Once the idea that a nearshore agile development stream could work become plausible, we adopted a kind of Shu-Ha-Ri technique with focus on designing and tailoring a fit process.
The process was to be followed by an initial small distributed team, before scaling up and further tweaking to the particularities of their day to day activities.

Outcome

While we initially joined to help and team up with local IT to increase delivery capabilities on commercial projects, the results were so encouraging that the business owner decided it now properly meet conditions to start own product development - a technical framework for rapid software development.
In the meanwhile we`ve also gained a strong base of supporters amongst our development colleagues from the customer IT department. We are proud to be part of the joint team building the new framework that enables an overall greater business agility for our customer.