Technology Booster

Technology Booster

7 min read.

A lot of knowledge is needed in the team to get a project started well. It can be beneficial to get outside help the first 5 weeks of the Project Development Phase to ensure a good track to run on.

After 5 weeks you want to have a demo-able solution running that uses emulated data based on the correct visual principles. This allows business management to adjust the direction early and/or identify marketing opportunities.

Together with early solution demo we like to write documents detailing the road ahead in terms of outstanding features and the principles to build on. This helps,

Start with Design and Innovation

Before you start the project development phase you should have an Design and Innovation Phase. The kick off is a series of workshops where we work with Stakeholders and Experts in the company to prototype how the product should actually work. The outcome is ideally an interactive prototype that shows how the finished product should work. This is invaluable for the people that have to make it real.

You can make such a phase short, but it should ideally be around 5 weeks to enable a good exploration of options. Anything longer will probably turn into a project of it’s own with vague outcomes. By having some of the future avenues captured, the team will know what might be coming in future versions. Sometimes it helps to ensure that the software developed can be modified to support Use Cases that were deferred to future versions. Capturing “dumb” ideas often helps clarify why what we do is a good idea.

The series of workshops done during Design and Innovation Phase helps,

Here are some of our favorite design books these days,

Gamestorming Design Sprint Sketching User Experience Practical Design Design for Real Life Design for Emotion

By the end of these first 5 weeks top management and the lead developer should have solid sense of the current business case, what problems the new product will solve, and how the business is meant to evolve together with the product. There will be a number of alternate cases in a rapid sketch form, which might be revisited in the future to recalibrate conversations and decisions. The outcome, a presentation of what product the team must build, is in the form of an interactive prototype that has been tested on a handful of potential future users, where everybody involved are clear that the pros and cons are the right ones.

Technology + Design Advisory

Kick-Start in Krakow

We worked together with friends from FastFin on getting a project off the ground for a Private Bank. The initial 6 weeks were carried out in at Headquarters where the business case was built along with an interactive prototype.

By having a working prototype discussions about what needs to be done and if something needs to work differently becomes much more concrete. It also allows early testing and evaluating with prospective users possible. That can make or break the real world success.

In the end the Bank wasn’t looking to tick boxes, but really wanted to make a good product so management joined with us during the workshops for the initial 6 weeks.

This was followed up with workshops in Poland together with the development and testing team. By working directly together we went through the most important usability aspects and made some key adjustments while making sure that the development team understood what the important elements were, and how the application should feel to use.

While having daily discussions with the local team, we worked to set up a good foundation and structure for the source code. This is like when starting to write a book you want to plan how it is structured in terms of chapters, story progression, plot, character development and the society it happens within. You can get stated by copying the structure from your previous book, but the longer you continue the more you get stuck in a cliché. If you copy how you have done things for the past 10 or 20 years, you are certain to struggle. The nature of Web Technology solutions today is very different from what most enterprises are used to. An extra challenge is that many principles, that are going to work best, are also not the ones you can read in a book about “Lean Code” or “Agile Programming”, but rather principles derived from prototyping and scoping the project.

We also had time to do a bit of technology education with the team on using Angular 2+. Unfortunately our visit clashed with holidays and conference attendance for the team, so we didn’t do as much as we ideally wanted. With an additional 5th week, which we would have preferred, we would have done a lot more.

One of the best influences we managed to produce might have been the daily connection through stand-ups and ad-hoc discussions. This allowed team members to gain knowledge and review solutions informally without fear of judgement from superiors.

During de-briefing the local team lead gave us this feedback,

Team Lead
"If you hadn't been here to kick off the project, we wouldn't have gotten any further by now, but instead we have a great basis for delivering the project on time."

We can only say that we’re happy to have accomplished that mission.

Next Up

We’re busy with an Angular development coaching project which we hope to write more about.

Lessons Learned

In our next project we have a list of lessons we want to teach the team,

A shift in best practice for software development that has occurred in recent years is the concept of Pull Request Review. It has big implication of quality, team communication and learning. In future projects we want to explore this much more with our clients.

Once again we saw an overworked Corporate Visual Design team that had a decent design guideline with loads of open question. In this instance it was based on Twitter bootstrap. It was a good effort of adaptation, but it had a number of shortcomings.

The last point is a classic corporate poison that we strongly recommend to management to counter. There is nothing in the styleguide that is confidential or proprietary, and 90% is Open Source to begin with. However Banks treat everything as classified by default due to banking regulation. Software development greatly benefits by being done in the open without confidentiality scares, so there is actually a great opportunity for organisational design teams to develop their common language in the open like they do at Swisscom Branding. For the love of your company, put Design, Marketing and UI Software under different governance. This is of course completely opposite to deploying corporate software, which must be done with a high level of security lockdown.

Our Process