Technology Booster 7 min read.

Technology Booster

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.

  • Create a sense of momentum from the first day among Engineers, Designers, Testers and Managers
  • Introduce modern software tools and technologies
  • Spread a solid understanding of the Usability required on a daily basis
  • Implement a good styling basis aligned with target audience, Corporate Style Guide and future direction.
  • Help evolve and improve the Corporate communication style and approach
  • Increase know-how on Web Technologies and modern JavaScript
  • Coach a balance between proven approach and latest trends
  • Enable the marketing plan for the project around launch

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,

  • On board developers during the initial phase or during maintenance
  • Repeating the good parts on future projects
  • Constructive debates about features based on why it was made that way in the first place

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,

  • Put top decider and hands-on people together in a creative process
  • Avoid poorly thought out product evaluation
  • Get early feedback from real users
  • Catch changing business context early
  • Capture the detailed understanding at top of organisation
  • Enable better communication across organisation layers
  • Avoid making a project that fails to be useful
  • Enable a visual and tactile evaluation of end product early
  • Make decision making more efficient by basing it on interaction + critique
  • Giving a counterweight to entrenched thought

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,

  • How do designers think differently about problem solving?
  • The difference between PC, Web and Mobile Phone User Interfaces
  • How modern web technology makes it less web-like
  • How to structure product development around a implementation skeleton
  • Networking, Connectivity, Auth, etc of Web Applications
  • Reactive Web Pages
  • The different mindset of Web User Interface and Web Servers

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.

  • There was only one example implementation, that everybody copied.
  • The example was bulky rather than lean, resulting is lots of confusing gunk on all projects.
  • While the team actually welcomed better solutions, the style guide felt prescriptive
  • The CSS matched how to do it in 2010. It didn’t really take advantage of Web Technology anno 2017.
  • It was trapped behind the corporate firewall, and everybody feared sending it to people outside.

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