Book
  • Introduction
  • Welcome !!
  • Chapter 1: The mobile ecosystem
    • Fragmentation is the devil
    • There is more than one type of mobile app
    • ... more than one type of app
    • ... one type of app
    • Under pressure (ee da de da de) !!
    • Further reading!!
  • Chapter 2: Let's start with design thinking
    • A taste of design thinking
    • The five steps
    • Design for everybody
    • Accessibility in mobile apps
  • Chapter 3: Give me a context and I will give you an app
    • Users
    • Personas? Users ? What is the difference?
    • Please, help me to model the context
    • The context canvas
  • Chapter 4: Powerful models
    • Data architecture is the foundation of analytics
    • From data to information and knowledge
    • Information/Knowledge in our mobile ecosystem
    • Questions to ask yourselves when building and classifying questions
    • The visualization-data map
    • On the scene: describing how personas interact with your app
  • Chapter 5: A GUI is better than two thousand words
    • 'Good to Go:' Let's explore the Design Systems
    • Designing GUI Mocks
    • No prototype... no deal
  • Chapter 6: About mobile operating systems ... and other deamons
    • The Android OS ... son of LINUX
    • iOS son of Darwin? or is it iOS son of UNIX?
    • Kernels
  • Chapter 7: Yes, software architecture matters !!
    • Self-test time
    • About design and design constraints
    • Architects' mojo: styles and patterns
    • What you need is a tactic !!
    • Self-test time 2 (for real)
    • Further reading
  • Chapter 8: Finally... coding
    • MVC, MVVM, MV*, MV...What?
    • Programming models: the Android side
    • Hello Jetpack, my new friend... An Android Jetpack Introduction
    • Programming models: the iOS side
    • Controllers and more controllers
    • Flutter son of... simplicity
    • Programming models: Flutter?
    • Flutter: State matters... Let´s start simple
    • Flutter: State matters... Complex stuff ahead
    • Micro-optimizations
  • Chapter 9: Data pipeline
    • Generalities data pipelines
    • Data storage types
    • Types of data pipelines
  • Chapter 10: Error Retrieving Chapter 10
    • Eventual Connectivity on Mobile Apps
    • How to handle it on Android
  • Chapter 11: The jewel in the crown: Performance
    • As fast as a nail
    • Memory bloats
    • Energy leaks
    • Final thoughts
  • Chapter 12. Become a performance bugs exterminator
    • Weak or strong?
    • Micro-optimizations
    • The single thread game !!
    • Using multi-threading like a boss !!
    • Caching
    • Avoiding memory bloats
    • Further readings
Powered by GitBook
On this page

Chapter 2: Let's start with design thinking

PreviousFurther reading!!NextA taste of design thinking

Last updated 1 year ago

(By Mario Linares-Vásquez, Diana Solano-Beltrán, Cristian Vinasco-Castañeda)


Before starting this chapter, you should check the article by Viktorija G.

Funny right? Google "design fails" and you will find hundreds of funny examples.

Why do we care about design? As engineers, our main goals are to provide solutions to real life problems (in particular software-based solutions), and propose innovative ideas that will improve everyday activities. >Wait a second..., some social networks might not have improved everyday activities :smiley:.

Let's think about design as a mechanism that assures that we are building solutions, products, or services that can be innovative or will be accepted by a sample of the population. In the specific case of software engineers, design is a very powerful tool that helps build software solutions that achieve high quality as perceived by the users. Here, the meaning of quality is very important. Let's define quality as how good a solution is to satisfy/comply with stakeholder requirements. In this sense, quality includes not only the quality attributes of a software system, but also the ability of the system to provide the users with the right features (i.e., useful and expected features) implemented correctly (i.e., the features work in the expected way).

The ISO defines quality as "[t]he totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs". [^1]

If we ask you to make a list of the phases of the software development lifecycle that involve design.... our guess is that you will answer "duuh!! the design phase dudes". However, we would like to respectfully disagree with you and tell you that all the phases in a software development process must involve design. We design software structures using software engineering and architecture methods. We also design test cases and verification procedures to assure the quality of the system. We even design the features and GUIs of systems... and there is more. We design/tailor software processes to specific contexts.

Software systems are amazing structures that need to satisfy stakeholder requirements. Therefore, design is a must and an activity that concerns the whole software development lifecycle. However, how can we assure that design is involved in all the activities? "Easy": thinking always as designers!!!

[^1] http://www.fao.org/docrep/w7295e/w7295e03.htm

(Free photo by Mikael Kristenson on ).

Unsplash
"22+ Funny Design Fails Show Why You Need A Designer"