As a young Designer & Developer I was responsible for creating a GUI Design Tool for layout out User Interfaces and Printed Reports. The tool was used as one of the building stones of Microsoft Dynamics NAV and used by countless companies the world over since 1995.
The work was carried out over 4 years and covered standardising using a Style Guide, Published Documentation and Agile Development. I later followed up by helping to create certification courses.
Microsoft purchased Navision in 2001, and it remains a prominent subsidiary just north of Copenhagen, Denmark.
Work covered
1. GUI Guide
2. Agile Software Development in C++
3. Writing documentation for Publishing
4. Certified training
Lessons Learned
It is not often that you encounter a company that consistently produce a solid User Experience. Most companies produce products that superficially look similar and pretty decent, but when you scratch the surface they tend to fall apart and all the internal issues start to become visible.
Navision have turned out to be a reference point for great software for many that were involved in selling and customising it, and as someone that helped shape the initial version I've carried forward many observations and best practices. Scrum and Agile Development tries to capture one quality, but unlike the approach at Navision it gets mired in process and formula.
The division of responsibility for designing is another important lesson, expecting many different roles to contribute to the concluding design. The balance between central responsibility and final say and a broad feeling of responsibility in the organisation is one of the design ideals I learned from being there.
Another lesson is the put a lot of effort into clearly defining and documenting the design principles. In 1995, just like today most companies do too little of this.
How it applies to Today
Combining the long term planning and execution with fast iterations is one of the biggest challenges in Software Development.
* Creating and building a detailed and dedicated Style Guide or Design System is essential for the long term stability and development productivity.
* Building a solid codebase that gradually becomes stable can sometimes feel like an art
* Iterating on the solution rather than attempting to predict and plan every change in advance is required to be productive and deliver something that works.
* Core values raises the bar for the end product. If you have the right team members it stimulates them and produces an order of magnitude better product for a similar cost.
* Although I would strongly recommend automated testing, you can get to a launchable product without.
* Administrative software benefits from a layered know-how and education concept with ongoing investment into certified experts.
As a young Designer & Developer I was responsible for creating a GUI Design Tool for layout out User Interfaces and Printed Reports. The tool was used as one of the building stones of Microsoft Dynamics NAV and used by countless companies the world over since 1995.
The work was carried out over 4 years and covered standardising using a Style Guide, Published Documentation and Agile Development. I later followed up by helping to create certification courses.
Microsoft purchased Navision in 2001, and it remains a prominent subsidiary just north of Copenhagen, Denmark.
Work covered
1. GUI Guide
2. Agile Software Development in C++
3. Writing documentation for Publishing
4. Certified training
Lessons Learned
It is not often that you encounter a company that consistently produce a solid User Experience. Most companies produce products that superficially look similar and pretty decent, but when you scratch the surface they tend to fall apart and all the internal issues start to become visible.
Navision have turned out to be a reference point for great software for many that were involved in selling and customising it, and as someone that helped shape the initial version I've carried forward many observations and best practices. Scrum and Agile Development tries to capture one quality, but unlike the approach at Navision it gets mired in process and formula.
The division of responsibility for designing is another important lesson, expecting many different roles to contribute to the concluding design. The balance between central responsibility and final say and a broad feeling of responsibility in the organisation is one of the design ideals I learned from being there.
Another lesson is the put a lot of effort into clearly defining and documenting the design principles. In 1995, just like today most companies do too little of this.
How it applies to Today
Combining the long term planning and execution with fast iterations is one of the biggest challenges in Software Development.
* Creating and building a detailed and dedicated Style Guide or Design System is essential for the long term stability and development productivity.
* Building a solid codebase that gradually becomes stable can sometimes feel like an art
* Iterating on the solution rather than attempting to predict and plan every change in advance is required to be productive and deliver something that works.
* Core values raises the bar for the end product. If you have the right team members it stimulates them and produces an order of magnitude better product for a similar cost.
* Although I would strongly recommend automated testing, you can get to a launchable product without.
* Administrative software benefits from a layered know-how and education concept with ongoing investment into certified experts.
Ready to take off?
