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,

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.

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,

"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.

Caterine’s work on the project

Since the we started with an existing prototype Caterine started reviewing the Interaction principles currently there and implicit in the business. Several problems were mapped.

1. Trading applications contain a lot of data and numbers. Even experienced users easily get blinded by sameness.
2. Tables have little sense of information hierachy and priority.
3. When users visit they most often just want to view the latest status of recent and ongoing orders in full.
4. Identified an opportunity to add filtering and searching of the past trades. Solution with little visual clutter needed.
5. Manual trade workflow wasn’t defined in terms of interaction and data.
6. Customer On-boarding and Marketing had not been defined.

Information Architecture

Use two variations of the typical trading tables that shows recent orders differently from older ones. The most recent orders are always shown(no scrolling, no filtering). The order is described in a sentence with all relevant information the same way it is when entering the order. Below a traditional table was used for orders older than 24 hours. The number of columns were reduced the basic information normally needed. The older orders table isn’t restricted in height so scanning the orders is done by scrolling the whole page.

This avoids,

• Sameness between recent(important) and older(less relevant) orders.
• Extra need for scrolling
• Information overloading
• Horizontal scrolling of recent order information when the Web Browser is made narrow
• complexity in how scrolling works

It is common to for trading applications to duplicate old database UI paradigms with filters and sorting for each column. This approach adds a lot of clutter, and requires the column to be visible in order to filter or sort. You might for instance want to only see orders without a settlement date, but you actually don’t ever care about the actual date, so you want that column to always be hidden. This interaction is traditionally cumbersome. Adding an option to clear all filters is hard to add in a concise way. Hints such as icons take up additional space for every column adding to the minimum screen size for an application. This often helps make the interface unusable on most mobile devices, even though banking is slowly moving in that direction like everyone else.

As a full solution the second table gains a search box that can search across all fields and suggest options for hiding, filtering and ordering in addition to search. These different options are shown in an auto-complete drop-down in response to typing in the field.

A common task is to look up an order from a particular day. By adding a timeline atop the table the user can jump to a trade by simply clicking on the timeline.

An additional benefit of this approach is that we can implement a simplified search in version one, and gradually improve it. If the search features we’re making are tied to the UI visually(with buttons/inputs) we would have to leave parts disabled or change the UI with future releases.

Order Automation Adjustment

The main purpose of the application is to adjust how the system is buying or selling automatically on your behalf. This is done with a simple scale. Two numbers will give you a sense of how much we’re talking about and how different the two are, but little else. If you ask how badly do you want to sell this on a scale from 1 to 10? I might want you to explain the consequences of a 10 and a 1.

The system had two scales, so we opted for letters A to C for the first and numbers 1 to 10 for the second. When you adjust the setting, the system would also construct a sentence that indicates the consequences compared to lower and higher settings.

The option to manually trade didn’t have a workflow defined so a made an animated illustration of the information entered, feedback and flow of the process.

Marketing

Knowing the approach planned for marketing the product before finishing the design, allows the designer to tweak the design to make it communicate better in a marketing context such as product shots, adverts etc.

We asked questions from the customer perspective in addition to the usual user focus to understand their situation / context

• Is the product for current customers (existing account)? Or new customers (interacting for the first time)?
• How well-informed are your new users on average?
• How familiar are they with similar products?
• How motivated are they to get started?
• What is the general value proposition?

Value proposition: Easy, Control, transparency

To visualise the proposition Catherine created the following illustration:

On-boarding

When users enter the Live Site for the first time, they might be thinking “what should I do first”? or “I’m not sure how this app works”.

We want to ensure that the customer’s first experience with the app will be easy and productive right from the start. While the application seems very straight forward it would be a good idea to actually test that with real users and add appropriate improvements.

remove as much friction as possible, especially for getting started

We suggested that the best approach is to offer access to the app as a Demo without logging in. This way it is interactive, up to date, “real”, and visual. The information needed to describe it can be kept short because, “Just look at the demo, and click around” can be the answer to many questions. This would also help promotion efforts.

use visuals rather than text to explain workflow

In most cases, users are visually driven. Use visuals rather than text to explain workflow. Long chunks of text require more effort and will cause the reader to tune out. Screenshots and videos tours are usually effective ways to introduce your app to the users. The need for videos will be limited if a live demo is available.

Some products may be better suited to tutorial screens while others may be served better by using interactive tutorials. Tutorial screens are generally not the right solution if it means having too many of them. The user will want to get to the service rather than spend time reading and following the tutorial.

You should be able to opt out of a tour, and return to it later.

Automatic generation of screenshots /material

Every time there are changes in the app or user interface, the user documentation and screens should be updated, to reflect the most recent change and workflow. For instance, If there is a spelling mistake in the app, you first need to fix the file with the text, then you need to find out where the text is displayed in the app visually, then you need to find out where the screenshots are in the user doc and update that screenshot. This is where the automatic generation of screenshots come in handy.

Henrik’s work on the project

On this project Henrik participated in design discussions and sparing, but was largely involved in developing the initial version and technical UI choices.

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.